Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also make the relevant fixes to those drivers that use the period and
duty_cycle struct members in division operations, viz. replacing the
division operations with 64-bit division macros as appropriate.
Bug: 140290586
Link: https://www.spinics.net/lists/linux-pwm/msg11133.html
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ife96637115f8f704aef938291eb189cb29378afb
This reverts commit 79650f61a7 as it
causes merge issues with the 5.6-rc1 merge.
Bug: 140290586
Cc: Guru Das Srinagesh <gurus@codeaurora.org>
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I397f72b24bc9230cc04c35e77abf1f167147f4de
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also make the relevant fixes to those drivers that use the period and
duty_cycle struct members in division operations, viz. replacing the
division operations with 64-bit division macros as appropriate.
Bug: 140290586
Change-Id: Ibb8c7f007f4c11ebf8cf01e7a468cc9c29aa8b23
Link: https://www.spinics.net/lists/linux-pwm/msg11133.html
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
It is surprising for a PWM consumer when the variable holding the
requested state is modified by pwm_apply_state(). Consider for example a
driver doing:
#define PERIOD 5000000
#define DUTY_LITTLE 10
...
struct pwm_state state = {
.period = PERIOD,
.duty_cycle = DUTY_LITTLE,
.polarity = PWM_POLARITY_NORMAL,
.enabled = true,
};
pwm_apply_state(mypwm, &state);
...
state.duty_cycle = PERIOD / 2;
pwm_apply_state(mypwm, &state);
For sure the second call to pwm_apply_state() should still have
state.period = PERIOD and not something the hardware driver chose for a
reason that doesn't necessarily apply to the second call.
So declare the state argument as a pointer to a const type and adapt all
drivers' .apply callbacks.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
i.MX7ULP has TPM(Low Power Timer/Pulse Width Modulation Module) inside,
it can support multiple PWM channels, all the channels share same
counter and period setting, but each channel can configure its duty and
polarity independently.
There are several TPM modules in i.MX7ULP, the number of channels in TPM
modules are different, it can be read from each TPM module's PARAM
register.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
