pwm: Update PWM API for dynamic prescaler computation

[erwango]

As discussed in #5469, current PWM API prevents dynamic prescaler computation.

Indeed, using get_cycles_per_sec in pin_set prevents to adjust PWM prescaler to the requested cycle duration and hence imposes to set it before compilation. Hence PWM application is limited to work in the duration range matching harcoded prescaler value.

I propose to remove function get_cycles_per_sec from API and let driver compute it internally inside pin_set. It seems this function is not used today (not in PWM tests/samples at least).

Drivers should be able to handle directly pwm_pin_set_usec.

[henrikbrixandersen]

This needs rethinking after introduction of the PWM capture API functions, which also use the pwm_get_cycles_per_sec() API function.

[manoj153]

Is there a detection mechanism to log error that the provided period is not supported based on the base pre-scaler set value?

[pszkotak]

If I understand correctly with current implementation there is impossible to have e.g. LED blinking with higher period that 250ms using PWM based driver (as in https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/basic/blinky_pwm).

It limits some applications or makes a need for weird workarounds.

@carlescufi, @anangl, is it planned for development? Do you have any estimations?

Edit: Even with the proposed change limitations caused by the min PWM clock at 125kHz and max COUNTERTOP of 32767 still hold. Workarounds are needed for slow blinking use case anyway.