Remove the use of floating point to calculate in
`pwm_rpi_get_cycles_per_sec` to fixed point calculations that result in the
same value. There is still a division here, which is somewhat slow still,
but the end result about twice fast for the whole path through the led pwm
code.
Even better would be to cache these values, since there is no interface in
this driver to change the configuration past init time.
Signed-off-by: David Brown <david.brown@linaro.org>
If the `divider-int-0` or variations of these for each channel properties
are not specified, or if these is 0,
the driver dynamically configures the division ratio by specified cycles.
The driver will operate at the specified division ratio if a non-zero
value is specified for `divider-int-0`.
This is unchanged from previous behavior.
Please specify ``divider-int-0`` explicitly to make the same behavior as
before.
In addition, the default device tree properties related to the division
ratio have been removed.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
return value of pwm_rpi_get_clkdiv contains implicit conversions
from 'float' to 'double', triggered by floating-point operations
involving mixed data types.
Signed-off-by: Jannis Ruellmann <j.ruellmann@kunbus.com>
pwm_set_wrap() sets the TOP value, not the number of cycles.
Counter will run from 0 to TOP inclusive, generating TOP + 1 cycles.
To get n cycles, we need to set TOP to (n - 1).
The wrong setting made it impossible to achieve 100 % duty cycle, as
there was always one extra cycle.
Fixes: 7e0fff24c7 ("drivers: pwm: add pwm driver for rpi_pico")
Signed-off-by: Oliver Barta <o.barta89@gmail.com>
pwm_set_chan_level uses slice channels A(=0) or B(=1) and not Zephyr
channel (0..15). So PWM doesn't work for channels > 1. There is already
a function (pwm_rpi_channel_to_pico_channel) which does the right thing,
but it isn't used for pwm_set_chan_level.
Signed-off-by: Jan Hilsdorf <jan.hilsdorf@gmail.com>
David Brown