summaryrefslogtreecommitdiff
path: root/drivers/pwm/pwm-imx27.c
AgeCommit message (Collapse)Author
2020-03-30pwm: imx27: Remove unused include of of_device.hAnson Huang
There is nothing in use from of_device.h, remove it. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-03-30pwm: imx27: Ensure clocks being on iff the PWM is onUwe Kleine-König
Up to now the .probe() function didn't enable clocks and relied on the core to call the .get_state() callback to have the clock running. The latter enabled the needed clocks and kept them running if the PWM wass enabled. This only works correctly if the .get_state() callback is called exactly once and this single call happens before unused clocks are disabled by the clk core. The former wasn't true for a short period while commit 01ccf903edd6 ("pwm: Let pwm_get_state() return the last implemented state") applied and not reverted yet and might become wrong in the future. The latter isn't true any more since commit cfc4c189bc70 ("pwm: Read initial hardware state at request time") which results in a running PWM being stopped at boot time if for example the consumer lives in a kernel module that is only loaded after the clk core disabled unused clocks. So ensure .probe() is left with the clocks on if the PWM is running and .get_state() disables everything it enabled. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-03-30pwm: imx27: Don't disable clocks at device remove timeUwe Kleine-König
The .remove() callback is not supposed to modify hardware state. This is in the responsibility of the PWM consumer. After the PWM was disabled the clocks are off (apart from a bug that is fixed in the next patch), so unbinding the driver either stops the PWM (which it should not) or disables already disabled clocks yielding warnings from the clk core. So just drop the call to disable the clocks. (Which BTW was also in the wrong order because the call makes the PWM unfunctional and so should have come only after pwmchip_remove()). Fixes: 9f4c8f9607c3 ("pwm: imx: Add ipg clock operation") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-03-30pwm: imx27: Simplify helper function to enable and disable clocksUwe Kleine-König
pwm_imx27_clk_prepare_enable() took a pointer to a struct pwm_chip just to convert it to a struct pwm_imx27_chip pointer while all callers already have the latter. Ditto for pwm_imx27_clk_disable_unprepare(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-03-30pwm: imx27: Fix clock handling in pwm_imx27_apply()Uwe Kleine-König
pwm_imx27_apply() enables the clocks if the previous PWM state was disabled. Given that the clocks are supposed to be left on iff the PWM is running, the decision to disable the clocks at the end of the function must not depend on the previous state. Without this fix the enable count of the two affected clocks increases by one whenever ->apply() changes from one disabled state to another. Fixes: bd88d319abe9 ("pwm: imx27: Unconditionally write state to hardware") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-01-20pwm: imx27: Eliminate error message for defer probeAnson Huang
For defer probe error, no need to output error message which will cause confusion. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-12-09pwm: imx27: Unconditionally write state to hardwareThierry Reding
The i.MX driver currently uses a shortcut and doesn't write all of the state through to the hardware when the PWM is disabled. This causes an inconsistent state to be read back by consumers with the result of them malfunctioning. Fix this by always writing the full state through to the hardware registers so that the correct state can always be read back. Tested-by: Michal Vokáč <michal.vokac@ysoft.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-12-09pwm: imx27: Cache duty cycle register valueThierry Reding
The hardware register containing the duty cycle value cannot be accessed when the PWM is disabled. This causes the ->get_state() callback to read back a duty cycle value of 0, which can confuse consumer drivers. Tested-by: Michal Vokáč <michal.vokac@ysoft.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: Ensure pwm_apply_state() doesn't modify the state argumentUwe Kleine-König
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>
2019-09-21pwm: imx: Document known limitationsUwe Kleine-König
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-05-09pwm: imx27: Use devm_platform_ioremap_resource() to simplify codeAnson Huang
Use the new helper devm_platform_ioremap_resource() which wraps the platform_get_resource() and devm_ioremap_resource() together, to simplify the code. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-03-04pwm: imx27: Only enable the clocks once in .get_state()Uwe Kleine-König
Currently the function pwm_imx27_get_state() of enables the clocks once unconditionally at the start, a second time if the PWM is enabled and disables unconditionally at the end. Simplify that to enable once at the start and disable conditionally at the end. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-01-16pwm: imx: Signedness bug in imx_pwm_get_state()Dan Carpenter
"ret" only holds zero and negative error codes. It needs to be signed for the error handling to work. Fixes: 9f4c8f9607c3 ("pwm: imx: Add ipg clock operation") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-01-16pwm: imx: Split into two driversUwe Kleine-König
The two PWM implementations called v1 (for i.MX1 and i.MX21) and v2 (for i.MX27 and later) have nothing in common apart from needing two clocks named "per" and "ipg" and being integrated in a SoC named i.MX. So split the file containing the two disjunct drivers into two files and two complete separate drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [thierry.reding@gmail.com: fix a modular build issue] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>