From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:09
Hello,
This series adds support for atomic PWM update, or IOW, the capability
to update all the parameters of a PWM device (enabled/disabled, period,
duty and polarity) in one go.
It also adds support for initial PWM state retrieval (or hardware
readout), which should allow smooth handover between the bootloader and
Linux. For example, critical PWM users (like critical regulators
controlled by a PWM) can query the current PWM state, and adapt the PWM
config without having to disable/enable the PWM, or abruptly change the
period/dutycyle/polarity config.
In this version, I dropped all patches converting PWM users and PWM
drivers to the atomic API in order to limit the number of patches and
ease review. I plan to send the remaining patches once these ones have
been accepted.
If you want to test the series, or see the big picture, you can have a
look at this branch [1].
Best Regards,
Boris
[1]https://github.com/bbrezillon/linux-rk/tree/atomic-pwm
Changes since v5:
- fix bugs in pwm_apply_state() implementation
- drop already applied patches
- s/pstate/state/
- add pwm_apply_args() helper
- limit the series to core changes and required changes in PWM users code
Changes since v4:
- introduce pwm_args to expose per-board/platform config
- deprecate non-atomic APIs
- implement non-atomic functions as wrappers around atomic ones
- patch all PWM users to use the atomic API
- rename the ->reset_state() hook into ->get_state()
- drop most acks
- rework PWM config in the pwm-regulator driver
- patch sun4i and sti PWM drivers to support HW readout
Changes since v3:
- rebased on pwm/for-next after pulling 4.4-rc1
- replace direct access to pwm fields by pwm_get/set_xxx() helpers, thus
fixing some build errors
- split changes to allow each maintainer to review/ack or take the
modification through its subsystem
Changes since v2:
- rebased on top of 4.3-rc2
- reintroduced pwm-regulator patches
Changes since v1:
- dropped applied patches
- squashed Heiko's fixes into the rockchip driver changes
- made a few cosmetic changes
- added kerneldoc comments
- added Heiko's patch to display more information in debugfs
- dropped pwm-regulator patches (should be submitted separately)
Boris Brezillon (23):
pwm: introduce the pwm_args concept
pwm: use pwm_get/set_xxx() helpers where appropriate
clk: pwm: use pwm_get_args() where appropriate
hwmon: pwm-fan: use pwm_get_args() where appropriate
input: misc: max77693: use pwm_get_args() where appropriate
leds: pwm: use pwm_get_args() where appropriate
regulator: pwm: use pwm_get_args() where appropriate
fbdev: ssd1307fb: use pwm_get_args() where appropriate
backlight: pwm_bl: use pwm_get_args() where appropriate
backlight: lp8788: explicitly apply PWM config extracted from pwm_args
backlight: lp855x: explicitly apply PWM config extracted from pwm_args
backlight: lm3630a: explicitly apply PWM config extracted from
pwm_args
input: misc: max8997: explicitly apply PWM config extracted from
pwm_args
input: misc: pwm-beeper: explicitly apply PWM config extracted from
pwm_args
drm: i915: explicitly apply PWM config extracted from pwm_args
ARM: explicitly apply PWM config extracted from pwm_args
pwm: keep PWM state in sync with hardware state
pwm: introduce the pwm_state concept
pwm: move the enabled/disabled info into pwm_state
pwm: add the PWM initial state retrieval infra
pwm: add the core infrastructure to allow atomic update
pwm: update documentation
pwm: switch to the atomic API
Heiko Stübner (1):
pwm: add information about polarity, duty cycle and period to debugfs
Documentation/pwm.txt | 30 +++-
arch/arm/mach-s3c24xx/mach-rx1950.c | 6 +
drivers/clk/clk-pwm.c | 17 +-
drivers/gpu/drm/i915/intel_panel.c | 6 +
drivers/hwmon/pwm-fan.c | 26 ++-
drivers/input/misc/max77693-haptic.c | 17 +-
drivers/input/misc/max8997_haptic.c | 6 +
drivers/input/misc/pwm-beeper.c | 6 +
drivers/leds/leds-pwm.c | 11 +-
drivers/pwm/core.c | 214 ++++++++++++++--------
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-crc.c | 2 +-
drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
drivers/pwm/pwm-omap-dmtimer.c | 2 +-
drivers/pwm/pwm-pxa.c | 2 +-
drivers/pwm/pwm-sun4i.c | 3 +-
drivers/pwm/sysfs.c | 61 ++++---
drivers/regulator/pwm-regulator.c | 20 ++-
drivers/video/backlight/lm3630a_bl.c | 6 +
drivers/video/backlight/lp855x_bl.c | 6 +
drivers/video/backlight/lp8788_bl.c | 6 +
drivers/video/backlight/pwm_bl.c | 10 +-
drivers/video/fbdev/ssd1307fb.c | 11 +-
include/linux/pwm.h | 335 +++++++++++++++++++++++++++--------
24 files changed, 606 insertions(+), 201 deletions(-)
--
2.5.0
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:12
Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition or
directly hardcoded in PWM drivers).
Create a pwm_args struct to store this reference config, so that PWM users
can differentiate the current config from the reference one.
Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to
use pwm_args instead of pwm_get_period/polarity().
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 22 +++++++++++++++-------
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-pxa.c | 2 +-
include/linux/pwm.h | 32 ++++++++++++++++++++++++++++++++
4 files changed, 49 insertions(+), 9 deletions(-)
@@ -60,7 +60,7 @@ static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)return-EINVAL;/* Store constant period value */-pwm_set_period(pwm,DIV_ROUND_CLOSEST(NSEC_PER_SEC,freq));+pwm->args.period=DIV_ROUND_CLOSEST(NSEC_PER_SEC,freq);return0;}
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:21
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
Acked-by: Kamil Debski <redacted>
---
drivers/hwmon/pwm-fan.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
@@ -215,6 +218,7 @@ static int pwm_fan_probe(struct platform_device *pdev){structthermal_cooling_device*cdev;structpwm_fan_ctx*ctx;+structpwm_argspargs;structdevice*hwmon;intduty_cycle;intret;
@@ -233,11 +237,19 @@ static int pwm_fan_probe(struct platform_device *pdev)platform_set_drvdata(pdev,ctx);+/*+*FIXME:pwm_apply_args()shouldberemovedwhenswitchingtothe+*atomicPWMAPI.+*/+pwm_apply_args(ctx->pwm);+/* Set duty cycle to maximum allowed */-duty_cycle=ctx->pwm->period-1;+pwm_get_args(ctx->pwm,&pargs);++duty_cycle=pargs.period-1;ctx->pwm_value=MAX_PWM;-ret=pwm_config(ctx->pwm,duty_cycle,ctx->pwm->period);+ret=pwm_config(ctx->pwm,duty_cycle,pargs.period);if(ret){dev_err(&pdev->dev,"Failed to configure PWM\n");returnret;
@@ -303,14 +315,16 @@ static int pwm_fan_suspend(struct device *dev)staticintpwm_fan_resume(structdevice*dev){structpwm_fan_ctx*ctx=dev_get_drvdata(dev);+structpwm_argspargs;unsignedlongduty;intret;if(ctx->pwm_value=0)return0;-duty=DIV_ROUND_UP(ctx->pwm_value*(ctx->pwm->period-1),MAX_PWM);-ret=pwm_config(ctx->pwm,duty,ctx->pwm->period);+pwm_get_args(ctx->pwm,&pargs);+duty=DIV_ROUND_UP(ctx->pwm_value*(pargs.period-1),MAX_PWM);+ret=pwm_config(ctx->pwm,duty,pargs.period);if(ret)returnret;returnpwm_enable(ctx->pwm);
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:27
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
Acked-by: Jacek Anaszewski <redacted>
---
drivers/leds/leds-pwm.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:34
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:40
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/input/misc/pwm-beeper.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:44
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/video/backlight/lp8788_bl.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:50
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/input/misc/max8997_haptic.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:18:57
The PWM state, represented by its period, duty_cycle and polarity,
is currently directly stored in the PWM device.
Declare a pwm_state structure embedding those field so that we can later
use this struct to atomically update all the PWM parameters at once.
All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 8 ++++----
include/linux/pwm.h | 54 +++++++++++++++++++++++++++++++++++++++++------------
2 files changed, 46 insertions(+), 16 deletions(-)
@@ -268,7 +268,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,pwm->chip=chip;pwm->pwm=chip->base+i;pwm->hwpwm=i;-pwm->polarity=polarity;+pwm->state.polarity=polarity;radix_tree_insert(&pwm_tree,pwm->pwm,pwm);}
@@ -446,8 +446,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)if(err)returnerr;-pwm->duty_cycle=duty_ns;-pwm->period=period_ns;+pwm->state.duty_cycle=duty_ns;+pwm->state.period=period_ns;return0;}
From: Boris Brezillon <hidden> Date: 2016-04-14 19:19:03
Prepare the transition to PWM atomic update by moving the enabled/disabled
state into the pwm_state struct. This way we can easily update the whole
PWM state by copying the new state in the ->state field.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 13 +++++++++----
include/linux/pwm.h | 11 ++++++++---
2 files changed, 17 insertions(+), 7 deletions(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:19:24
From: Heiko Stübner <heiko@sntech.de>
The pwm-states make it possible to also output the polarity, duty cycle
and period information in the debugfs pwm summary-outout.
This makes it easier to gather overview information about pwms without
needing to walk through the sysfs attributes of every pwm.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 5 +++++
1 file changed, 5 insertions(+)
@@ -42,9 +42,26 @@ variants of these functions, devm_pwm_get() and devm_pwm_put(), also exist. After being requested, a PWM has to be configured using:-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);+int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);-To start/stop toggling the PWM output use pwm_enable()/pwm_disable().+This API controls both the PWM period/duty_cycle config and the+enable/disable state.++The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers+around pwm_apply_state() and should not be used if the user wants to change+several parameter at once. For example, if you see pwm_config() and+pwm_{enable,disable}() calls in the same function, this probably means you+should switch to pwm_apply_state().++The PWM user API also allows one to query the PWM state with pwm_get_state().++In addition to the PWM state, the PWM API also exposes PWM arguments, which+are the reference PWM config one should use on this PWM.+PWM arguments are usually platform-specific and allows the PWM user to only+care about dutycycle relatively to the full period (like, duty = 50% of the+period). struct pwm_args contains 2 fields (period and polarity) and should+be used to set the initial PWM config (usually done in the probe function+of the PWM user). PWM arguments are retrieved with pwm_get_args(). Using PWMs with the sysfs interface -----------------------------------
@@ -105,6 +122,15 @@ goes low for the remainder of the period. Conversely, a signal with inversed polarity starts low for the duration of the duty cycle and goes high for the remainder of the period.+Drivers are encouraged to implement ->apply() instead of the legacy+->enable(), ->disable() and ->config() methods. Doing that should provide+atomicity in the PWM config workflow, which is required when the PWM controls+a critical device (like a regulator).++The implementation of ->get_state() (a method used to retrieve initial PWM+state) is also encouraged for the same reason: letting the PWM user know+about the current PWM state would allow him to avoid glitches.+ Locking -------
From: Boris Brezillon <hidden> Date: 2016-04-14 19:20:21
Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic update.
This method will be preferred over the ->enable(), ->disable() and
->config() methods if available.
Add the pwm_apply_state() function to the PWM user API.
Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.
pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.
pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 186 +++++++++++++++++++++++-------------
include/linux/pwm.h | 269 +++++++++++++++++++++++++++++++++++-----------------
2 files changed, 302 insertions(+), 153 deletions(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:21:37
Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 3 +++
include/linux/pwm.h | 28 ++++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:22:05
Before the introduction of pwm_args, the core was resetting the PWM period
and polarity states to the reference values (those provided through the
DT, a PWM lookup table or hardcoded in the driver).
Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in
pwm_device_request().
We can also get rid of the pwm_set_period() call done in
pwm_apply_args(), because PWM users are now directly using pargs->period
instead of pwm_get_period(). By doing that we avoid messing with the
current PWM period.
The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).
Signed-off-by: Boris Brezillon <redacted>
---
drivers/pwm/core.c | 8 --------
include/linux/pwm.h | 1 -
2 files changed, 9 deletions(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:22:34
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
arch/arm/mach-s3c24xx/mach-rx1950.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:23:46
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/gpu/drm/i915/intel_panel.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:24:41
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/video/backlight/lm3630a_bl.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:25:40
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/video/backlight/lp855x_bl.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:26:54
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
---
drivers/video/fbdev/ssd1307fb.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:27:30
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
---
drivers/regulator/pwm-regulator.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
From: Boris Brezillon <hidden> Date: 2016-04-14 19:28:00
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
---
drivers/input/misc/max77693-haptic.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
@@ -329,6 +334,12 @@ static int max77693_haptic_probe(struct platform_device *pdev)returnPTR_ERR(haptic->pwm_dev);}+/*+*FIXME:pwm_apply_args()shouldberemovedwhenswitchingtothe+*atomicPWMAPI.+*/+pwm_apply_args(haptic->pwm_dev);+haptic->motor_reg=devm_regulator_get(&pdev->dev,"haptic");if(IS_ERR(haptic->motor_reg)){dev_err(&pdev->dev,"failed to get regulator\n");
From: Boris Brezillon <hidden> Date: 2016-04-14 19:28:36
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <redacted>
Acked-by: Stephen Boyd <redacted>
---
drivers/clk/clk-pwm.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
@@ -59,6 +59,7 @@ static int clk_pwm_probe(struct platform_device *pdev)structclk_init_datainit;structclk_pwm*clk_pwm;structpwm_device*pwm;+structpwm_argspargs;constchar*clk_name;structclk*clk;intret;
@@ -71,22 +72,28 @@ static int clk_pwm_probe(struct platform_device *pdev)if(IS_ERR(pwm))returnPTR_ERR(pwm);-if(!pwm->period){+pwm_get_args(pwm,&pargs);+if(!pargs.period){dev_err(&pdev->dev,"invalid PWM period\n");return-EINVAL;}if(of_property_read_u32(node,"clock-frequency",&clk_pwm->fixed_rate))-clk_pwm->fixed_rate=NSEC_PER_SEC/pwm->period;+clk_pwm->fixed_rate=NSEC_PER_SEC/pargs.period;-if(pwm->period!=NSEC_PER_SEC/clk_pwm->fixed_rate&&-pwm->period!=DIV_ROUND_UP(NSEC_PER_SEC,clk_pwm->fixed_rate)){+if(pargs.period!=NSEC_PER_SEC/clk_pwm->fixed_rate&&+pargs.period!=DIV_ROUND_UP(NSEC_PER_SEC,clk_pwm->fixed_rate)){dev_err(&pdev->dev,"clock-frequency does not match PWM period\n");return-EINVAL;}-ret=pwm_config(pwm,(pwm->period+1)>>1,pwm->period);+/*+*FIXME:pwm_apply_args()shouldberemovedwhenswitchingtothe+*atomicPWMAPI.+*/+pwm_apply_args(pwm);+ret=pwm_config(pwm,(pargs.period+1)>>1,pargs.period);if(ret<0)returnret;
From: Mark Brown <broonie@kernel.org> Date: 2016-04-15 06:56:09
On Thu, Apr 14, 2016 at 09:17:27PM +0200, Boris Brezillon wrote:
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
From: Krzysztof Kozlowski <hidden> Date: 2016-04-15 08:17:34
On 04/14/2016 09:17 PM, Boris Brezillon wrote:
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
arch/arm/mach-s3c24xx/mach-rx1950.c | 6 ++++++
1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <redacted>
Best regards,
Krzysztof
On Thu, Apr 14, 2016 at 09:17:33PM +0200, Boris Brezillon wrote:
quoted hunk
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/input/misc/max8997_haptic.c | 6 ++++++
1 file changed, 6 insertions(+)
@@ -304,6 +304,12 @@ static int max8997_haptic_probe(struct platform_device *pdev)error);gotoerr_free_mem;}++/*+*FIXME:pwm_apply_args()shouldberemovedwhenswitchingto+*theatomicPWMAPI.+*/+pwm_apply_args(chip->pwm);
I do not understand. We did not fetch/modify any args, what are we
applying and why? Especially since we saying we want to remove this
later.
Thanks.
--
Dmitry
From: Boris Brezillon <hidden> Date: 2016-04-17 15:39:37
Hi Dmitry,
On Sun, 17 Apr 2016 05:45:48 -0700
Dmitry Torokhov [off-list ref] wrote:
On Thu, Apr 14, 2016 at 09:17:33PM +0200, Boris Brezillon wrote:
quoted
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <redacted>
---
drivers/input/misc/max8997_haptic.c | 6 ++++++
1 file changed, 6 insertions(+)
@@ -304,6 +304,12 @@ static int max8997_haptic_probe(struct platform_device *pdev)error);gotoerr_free_mem;}++/*+*FIXME:pwm_apply_args()shouldberemovedwhenswitchingto+*theatomicPWMAPI.+*/+pwm_apply_args(chip->pwm);
I do not understand. We did not fetch/modify any args, what are we
applying and why? Especially since we saying we want to remove this
later.
This is part of the process to allow some PWM users to retrieve the
current PWM state instead of blindly applying a new config. This is
particularly useful when one want a smooth handover between the
bootloader and the kernel, and we have a real case here with a critical
regulator (controlling the DDR voltage) controlled by a PWM device:
the bootloader setup the PWM to 1.2V, and we want the kernel to
retrieve the current PWM config and adjust the duty_cycle according to
the PWM arguments provided by the DT definition.
So, now let's switch to the actual reason for calling pwm_apply_args()
directly from PWM users code. The operations done in pwm_apply_args()
were previously done by the core when the user was requesting the PWM.
Those operations consisted in initializing the PWM period and polarity
to the values specified in the DT or PWM lookup table (what we call
pwm_args).
This is working fine as long as we don't care about the initial PWM
state, but as explained above, that may no longer be the case. That's
why we want PWM users to explicitly state that they don't care about the
initial PWM state and want to apply the default state instead:
period = pwm_args.period and polarity = pwm_args.polarity.
Once all PWM users have been patched to explicitly call
pwm_apply_args(), we'll be able to remove this call from the core
(patch 17), and let PWM drivers implement ->get_state() to provide
hardware readout (patch 20).
PWM users that are interested in adjusting existing PWM config to the
polarity and period specified in pwm_args will be able to do so instead
of calling pwm_apply_args(). And for those who just don't care about
initial state, they should just call pwm_apply_state() with the initial
state they expect instead of pwm_apply_args(), which is only partially
describing the PWM config (PWM args don't specify whether the PWM
should be disabled or enabled, and what duty_cycle to use).
Hope this clarifies a bit the situation.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com