Hello,
On Thu, Sep 05, 2024 at 01:09:48AM +0200, Benjamin Larsson wrote:
> 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 ?
IIUC that means to add:
On configuration the currently running period is completed.
to the Limitations paragraph.
> 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.
1 second long pulses with a period size of 1 second, so a constant high
signal?
Another thing that would be interesting is, if it can happen that you
get a mixed signal. That is, if you update from
.period = A
.duty_cycle = B
to
.period = C
.duty_cycle = D
that you get one period with length C and duty_cycle B when the period
completes after configuring period but before duty_cycle.
Best regards
UWe
Attachment:
signature.asc
Description: PGP signature
