pwm: fsl-ftm: More relaxed permissions for updating period

pwm: fsl-ftm: More relaxed permissions for updating period

The Flextimer has only one period for several channels. The PWM
subsystem doesn't allow to model something like that. The current
implementation simply disallows changing the period once it has
been set, having as a side effect that you need to enable and
disable the PWM if you want to change the period.

The driver should allow as much freedom as possible for configuring
the period and duty cycle. Therefore, this patch reworks the code
to allow the following:

- period and duty_cycle can be set at will when the PWM is disabled;
- when enabling a PWM, verify that the period is either not set yet,
  or the same as the other already enabled PWM(s), and fail if not;
- allow to change the period on the fly when the PWM is the only one
  enabled.

It also allows to have different periods configured for different PWMs.
Only one period can be used at a time, thus the first PWM to be enabled
will set that period, only other PWMs with that same period can be
enabled at the same time. To use another PWM with another period, the
enabled PWMs must be disabled first.

Example scenario :
echo 5000000 > pwm0/period	#OK
echo 1000000 > pwm0/duty_cycle	#OK
echo 1000000 > pwm1/period	#OK
echo 1000000 > pwm1/duty_cycle	#OK
echo 1 > pwm0/enable		#OK
echo 1 > pwm1/enable		#FAIL (pwm0/period != pwm1/period)
echo 0 > pwm0/enable		#OK
echo 1 > pwm1/enable		#OK
echo 1000000 > pwm0/period	#OK
echo 2000000 > pwm0/period	#OK
echo 1 > pwm0/enable		#FAIL (pwm0/period != pwm1/period)
echo 2000000 > pwm1/period	#OK (pwm1 still running, changed on the fly)
echo 1 > pwm0/enable		#OK (now pwm0/period == pwm1/period)
echo 3000000 > pwm1/period	#FAIL (other PWMs running)
echo 0 > pwm0/enable		#OK
echo 3000000 > pwm1/period	#OK (only this PWM running)

Adapting the code to satisfy these constraints turned up a number of
additional issues with the current implementation:
- the prescaler value 0 was not used (when it could have been);
- when setting the period was not possible, the internal state was
  inconsistent;
- the maximal value for configuring the period was never used;

Since all of these interact with each other, rather than trying to fix
each individual issue, this patch reworks how the period and duty cycle
are set entirely, with the following additional improvements:
- implement the new apply() method instead of the individual methods;
- return the exact used period/duty_cycle values;
- more coherent argument types for period, duty_cycle;

Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>