04 Jan, 2021
1 commit
-
This is the 5.10.4 stable release
* tag 'v5.10.4': (717 commits)
Linux 5.10.4
x86/CPU/AMD: Save AMD NodeId as cpu_die_id
drm/edid: fix objtool warning in drm_cvt_modes()
...Signed-off-by: Jason Liu
Conflicts:
drivers/gpu/drm/imx/dcss/dcss-plane.c
drivers/media/i2c/ov5640.c
30 Dec, 2020
1 commit
-
[ Upstream commit 1ce65396e6b2386b4fd54f87beff0647a772e1cd ]
The second parameter of do_div is an u32 and NSEC_PER_SEC * prescale
overflows this for bigger periods. Assuming the usual pwm input clk rate
of 66 MHz this happens starting at requested period > 606060 ns.Splitting the division into two operations doesn't loose any precision.
It doesn't need to be feared that c / NSEC_PER_SEC doesn't fit into the
unsigned long variable "duty_cycles" because in this case the assignment
above to period_cycles would already have been overflowing as
period >= duty_cycle and then the calculation is moot anyhow.Fixes: aef1a3799b5c ("pwm: imx27: Fix rounding behavior")
Signed-off-by: Uwe Kleine-König
Tested-by: Johannes Pointner
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
14 Dec, 2020
1 commit
-
The PWM in i.MX8qxp MIPI subsystem needs to use the
'32k' clock to work properly. This patch gets this
clock in the PWM driver and uses it if it is supplied.Signed-off-by: Liu Ying
16 Jun, 2020
1 commit
-
Since the PWM framework is switching struct pwm_state.period's
datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULL to handle a 64-bit dividend.Signed-off-by: Guru Das Srinagesh
Signed-off-by: Thierry Reding
02 Jun, 2020
1 commit
-
To not trigger the warnings provided by CONFIG_PWM_DEBUG
- use up-rounding in .get_state()
- don't divide by the result of a division
- don't use the rounded counter value for the period length to calculate
the counter value for the duty cycleSigned-off-by: Uwe Kleine-König
Signed-off-by: Thierry Reding
30 Mar, 2020
5 commits
-
There is nothing in use from of_device.h, remove it.
Signed-off-by: Anson Huang
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding
20 Jan, 2020
1 commit
-
For defer probe error, no need to output error message which
will cause confusion.Signed-off-by: Anson Huang
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding
09 Dec, 2019
2 commits
-
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áč
Tested-by: Adam Ford
Signed-off-by: Thierry 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áč
Tested-by: Adam Ford
Signed-off-by: Thierry Reding
21 Sep, 2019
2 commits
-
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
Signed-off-by: Thierry Reding -
Signed-off-by: Uwe Kleine-König
Signed-off-by: Thierry Reding
09 May, 2019
1 commit
-
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
Acked-by: Uwe Kleine-König
Reviewed-by: Mukesh Ojha
Signed-off-by: Thierry Reding
04 Mar, 2019
1 commit
-
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
Signed-off-by: Thierry Reding
16 Jan, 2019
2 commits
-
"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
Reviewed-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
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
[thierry.reding@gmail.com: fix a modular build issue]
Signed-off-by: Thierry Reding
