Commit Graph

33 Commits

Author SHA1 Message Date
Fabio Estevam a4aae5afc9 regulator: pwm-regulator: Remove unneeded gpiod NULL check
The gpiod API checks for NULL descriptors, so there is no need to
duplicate the check in the driver.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2017-07-24 16:26:35 +01:00
Matthias Kaehlcke 73e705bf81 regulator: core: Add set_voltage_time op
The new op is analogous to set_voltage_time_sel. It can be used by
regulators which don't have a table of discrete voltages. The function
returns the time for the regulator output voltage to stabilize after
being set to a new value, in microseconds. If the op is not set a
default implementation is used to calculate the delay.

This change also removes the ramp_delay calculation in the PWM
regulator, since the driver now uses the core code for the calculation
of the delay.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-16 18:38:22 +01:00
Boris Brezillon ea398e2873 regulator: pwm: Support extra continuous mode cases
The continuous mode allows one to declare a PWM regulator without having
to declare the voltage <-> dutycycle association table. It works fine as
long as your voltage(dutycycle) function is linear, but also has the
following constraints:

- dutycycle for min_uV = 0%
- dutycycle for max_uV = 100%
- dutycycle for min_uV < dutycycle for max_uV

While the linearity constraint is acceptable for now, we sometimes need to
restrict of the PWM range (to limit the maximum/minimum voltage for
example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be
tweaked with PWM polarity, but not all PWMs support inverted polarity).

Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define
such constraints. If those properties are not defined, the PWM regulator
use the default pwm-dutycycle-range = <0 100> and
pwm-dutycycle-unit = <100> values (existing behavior).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-25 15:34:06 +02:00
Boris Brezillon d9070fdbe4 regulator: pwm: Retrieve correct voltage
The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.

Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:44:29 +02:00
Boris Brezillon 87248991a1 regulator: pwm: Properly initialize the ->state field
The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current
voltage value.
If possible, retrieve the current voltage selector from the PWM state,
else return -EINVAL.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:43:24 +02:00
Boris Brezillon 3f4eb39be9 regulator: pwm: Switch to the atomic PWM API
Use the atomic API wherever appropriate and get rid of pwm_apply_args()
call (the reference period and polarity are now explicitly set when
calling pwm_apply_state()).

We also make use of the pwm_set_relative_duty_cycle() helper to ease
relative to absolute duty_cycle conversion.

Note that changes introduced by commit fd786fb027 ("regulator: pwm:
Try to avoid voltage error in duty cycle calculation") are no longer
needed because pwm_set_relative_duty_cycle() takes care of all rounding
approximation for us.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:43:21 +02:00
Boris Brezillon fd4f99c4c3 regulator: pwm: Adjust PWM config at probe time
The PWM attached to a PWM regulator device might have been previously
configured by the bootloader.
Make sure the bootloader and linux config are in sync, and adjust the PWM
config if that's not the case.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:41:37 +02:00
Douglas Anderson c2588393e6 regulator: pwm: Fix regulator ramp delay for continuous mode
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly.  It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS.  Let's
adjust it.  Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).

Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
and use 10%.

NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
That could be done in a future patch when someone has a user of that
featre.

Though this patch is shows as "fixing" a bug, there are no actual known
users of continuous mode PWM regulator w/ ramp delay in mainline and so
this likely won't have any effect on anyone unless they are working
out-of-tree with private patches.  For anyone in this state, it is
highly encouraged to also pick Boris Brezillon's WIP patches to get
yourself a reliable and glitch-free regulator.

Fixes: 4773be185a ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-07 11:45:06 +02:00
Alexandre Courbot 27bfa8893b regulator: pwm: Support for enable GPIO
Add an optional enable GPIO to the pwm-regulator driver.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-23 11:34:35 +01:00
Boris Brezillon 830583004e regulator: pwm: Drop unneeded pwm_enable() call
Now that the PWM regulator driver implements the ->enable/disable() hooks
we can remove the pwm_enable() call from pwm_regulator_set_voltage().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-03 11:42:48 +01:00
Mark Brown bc0868c62b Merge branch 'for-4.7/pwm-regulator' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm into regulator-pwm 2016-05-03 15:09:56 +01:00
Boris Brezillon 8c12ad8e91 regulator: pwm: Use pwm_get_args() where appropriate
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 <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:46:50 +02:00
Laxman Dewangan fd786fb027 regulator: pwm: Try to avoid voltage error in duty cycle calculation
In continuous mode of the PWM regulators, the requested voltage
PWM duty cycle is calculated in terms of 100% scale where entire
range denotes 100%. The calculation for PWM pulse ON time(duty_pulse)
is done as:

	duty_cycle = ((requested - minimum) * 100) / voltage_range.

then duty pulse is calculated as
	duty_pulse = (pwm_period/100) * duty_cycle

This leads to the calculation error if we have the requested voltage
where accurate pulse time is possible.
For example: Consider following case
	voltage range is 800000uV to 1350000uV.
	pwm-period = 1550ns (1ns time is 1mV).

	Requested 900000uV.

	duty_cycle = ((900000uV - 800000uV) * 100)/ 1550000
		   = 6.45 but we will get 6.

	duty_pulse = (1550/100) * 6 = 90 pulse time.

90 pulse time is equivalent to 90mV and this gives us pulse time equivalent
to 890000uV instead of 900000uV.

Proposing the solution in which if requested voltage makes the accurate
duty pulse then there will not be any error. On this case, if
(req_uV - min_uV) * pwm_period is perfect dividable by voltage_range
then get the duty pulse time directly.

	duty_pulse = ((900000uV - 800000uV) * 1550)/1550000)
		   = 100

and this is equivalent to 100mV and so final voltage is
(800000 + 100000) = 900000uV which is same as requested,

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-05 11:39:25 -07:00
Laxman Dewangan 5bf59bd5e9 regulator: pwm: Prints error number along with detail
Prints the error number along with error message when any
error occurs. This help on getting the reason of failure
quickly from log without any code instrument.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-15 08:51:28 +00:00
Laxman Dewangan f907a0a949 regulator: pwm: Add support to have multiple instance of pwm regulator
Some of platforms like Nvidia's Tegra210 Jetson-TX1 platform has
multiple PMW based regulators. Add support to have multiple instances
of the driver by not changing any global data of pwm regulator and
if required, making instance specific copy and then making changes.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-12 13:07:13 +07:00
Laxman Dewangan 1aaab34878 regulator: pwm: Fix calculation of voltage-to-duty cycle
With following equation for calculating
voltage_to_duty_cycle_percentage
	100 - (((req_uV * 100) - (min_uV * 100)) / diff);

we get 0% for max_uV and 100% for min_uV.

Correcting this to
	((req_uV * 100) - (min_uV * 100)) / diff;
 to get proper duty cycle.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-12 13:07:09 +07:00
Boris Brezillon 1de7d80246 regulator: pwm: implement ->enable(), ->disable() and ->is_enabled methods
Implement the ->enable(), ->disable() and ->is_enabled methods and remove
the PWM call in ->set_voltage_sel().
This is particularly important for critical regulators tagged as always-on,
because not claiming the PWM (and its dependencies) might lead to
unpredictable behavior (like a system hang because the PWM clk is only
claimed when the PWM device is enabled).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-21 14:11:18 -07:00
Lee Jones 60cb65ebf4 regulator: pwm-regulator: Fix ' comparison between signed and unsigned integer' warning
drivers/regulator/pwm-regulator.c:
  In function ‘pwm_regulator_init_table’:
drivers/regulator/pwm-regulator.c:171:14:
  warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-10 19:34:06 +01:00
Lee Jones b343e08f3c regulator: pwm-regulator: Fix 'used uninitialized' warning
drivers/regulator/pwm-regulator.c:
  In function 'pwm_regulator_init_table':
drivers/regulator/pwm-regulator.c:172:14:
  warning: 'length' is used uninitialized in this function [-Wuninitialized]
    if ((length < sizeof(*duty_cycle_table)) ||
              ^
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-10 19:34:06 +01:00
Lee Jones f293634b5a regulator: pwm-regulator: Fix 'unused-variable' warning
drivers/regulator/pwm-regulator.c:
  In function 'pwm_regulator_init_continuous':
drivers/regulator/pwm-regulator.c:202:22:
  warning: unused variable 'np' [-Wunused-variable]
     struct device_node *np = pdev->dev.of_node;
              ^
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-10 19:34:06 +01:00
Lee Jones f3f6439d86 regulator: pwm-regulator: Small clean-ups
Remove over-bracketing, use framework API to fetch PWM period and
be more forthcoming that pwm_voltage_to_duty_cycle() actually returns
duty cycle as a percentage, rather than a register value.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-09 18:54:25 +01:00
Lee Jones f747a1fe78 regulator: pwm-regulator: Remove obsoleted property
In "[3d7ef30] regulator: pwm-regulator: Simplify voltage to duty-cycle
call" we stopped using max_duty_cycle, so we can retire it from device
data and DT.

There is no need to deprecate this property, as it hasn't hit Mainline
yet.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-09 18:54:24 +01:00
Lee Jones 5ad2cb14f5 regulator: pwm-regulator: Don't assign structure attributes right away
Perhaps this is just personal preference, but ...

This patch introduces a new local variable to receive and test regulator
initialisation data.  It simplifies and cleans up the code making it
that little bit easier to read and maintain.  The local value is assigned
to the structure attribute when all the others are.  This is the way we
usually do things.

Prevents this kind of nonsense:

	this->is->just.silly = fetch_silly_value(&pointer);
	if (!this->is->just.silly) {
		printk("Silly value failed: %d\n", this->is->just.silly);
		return this->is->just.silly;
	}

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-07 18:58:28 +01:00
Lee Jones cae897dec2 regulator: pwm-regulator: Simplify voltage to duty-cycle call
If we reverse some of the logic and change the formula used,
we can simplify the function greatly.

It is intentional that this function is supplied and then re-worked
within the same patch-set.  The submission in the previous patch is
the tried and tested (i.e. in real releases) method written by ST.
This patch contains a simplification provided later.  It looks and
performs better, but doesn't have the same time-under-test that the
original method does.  The idea is that we keep some history in
order to provide an easy way back i.e. revert.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-07 18:58:28 +01:00
Lee Jones 4773be185a regulator: pwm-regulator: Add support for continuous-voltage
The current version of PWM regulator only supports a static table
approach, where pre-calculated values are supplied by the vendor and
obtained via DT.  The continuous-voltage method takes min_uV and
max_uV, and divides the difference between them up into a number of
slices.  The number of slices depend on how large the duty cycle
register is.  This information is provided by a DT property.

As the name alludes, this provides values for a continuous voltage
range between min_uV and max_uV, which has obvious benefits over
either limited voltage possibilities, or the requirement to provide
a large voltage-table.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-07 18:58:27 +01:00
Lee Jones f9178dad67 regulator: pwm-regulator: Separate voltage-table initialisation
Take this out of the main .probe() routine in order to facilitate the
introduction of different ways to obtain 'duty cycle' information.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-07 14:27:55 +01:00
Lee Jones ab101e3544 regulator: pwm-regulator: Diffientiate between dev (device) and rdev (regulator_dev)
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-08 19:18:19 +01:00
Lee Jones c779cebb7d regulator: pwm-regulator: Remove superfluous is_enabled check
The core framework already takes care of this.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-08 19:18:19 +01:00
Lee Jones b6f55e74d2 regulator: pwm-regulator: Remove unnecessary descriptor attribute from ddata
The Regulator Device keeps a full copy of it's own, which can be easily accessed.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-08 19:18:19 +01:00
Linus Torvalds e6b5be2be4 Driver core patches for 3.19-rc1
Here's the set of driver core patches for 3.19-rc1.
 
 They are dominated by the removal of the .owner field in platform
 drivers.  They touch a lot of files, but they are "simple" changes, just
 removing a line in a structure.
 
 Other than that, a few minor driver core and debugfs changes.  There are
 some ath9k patches coming in through this tree that have been acked by
 the wireless maintainers as they relied on the debugfs changes.
 
 Everything has been in linux-next for a while.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iEYEABECAAYFAlSOD20ACgkQMUfUDdst+ylLPACg2QrW1oHhdTMT9WI8jihlHVRM
 53kAoLeteByQ3iVwWurwwseRPiWa8+MI
 =OVRS
 -----END PGP SIGNATURE-----

Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core update from Greg KH:
 "Here's the set of driver core patches for 3.19-rc1.

  They are dominated by the removal of the .owner field in platform
  drivers.  They touch a lot of files, but they are "simple" changes,
  just removing a line in a structure.

  Other than that, a few minor driver core and debugfs changes.  There
  are some ath9k patches coming in through this tree that have been
  acked by the wireless maintainers as they relied on the debugfs
  changes.

  Everything has been in linux-next for a while"

* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
  Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
  fs: debugfs: add forward declaration for struct device type
  firmware class: Deletion of an unnecessary check before the function call "vunmap"
  firmware loader: fix hung task warning dump
  devcoredump: provide a one-way disable function
  device: Add dev_<level>_once variants
  ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
  ath: use seq_file api for ath9k debugfs files
  debugfs: add helper function to create device related seq_file
  drivers/base: cacheinfo: remove noisy error boot message
  Revert "core: platform: add warning if driver has no owner"
  drivers: base: support cpu cache information interface to userspace via sysfs
  drivers: base: add cpu_device_create to support per-cpu devices
  topology: replace custom attribute macros with standard DEVICE_ATTR*
  cpumask: factor out show_cpumap into separate helper function
  driver core: Fix unbalanced device reference in drivers_probe
  driver core: fix race with userland in device_add()
  sysfs/kernfs: make read requests on pre-alloc files use the buffer.
  sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
  fs: sysfs: return EGBIG on write if offset is larger than file size
  ...
2014-12-14 16:10:09 -08:00
Javier Martinez Canillas 072e78b12b regulator: of: Add regulator desc param to of_get_regulator_init_data()
The of_get_regulator_init_data() function is used to extract the regulator
init_data but information on how to extract certain data is defined in the
static regulator descriptor (e.g: how to map the hardware operating modes).

Add a const struct regulator_desc * parameter to the function signature so
the parsing logic could use the information in the struct regulator_desc.

of_get_regulator_init_data() relies on of_get_regulation_constraints() to
actually extract the init_data so it has to pass the struct regulator_desc
but that is modified on a later patch.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
2014-11-26 18:58:14 +00:00
Wolfram Sang 6c794b2654 regulator: drop owner assignment from platform_drivers
A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-10-20 16:21:29 +02:00
Chris Zhong aa66cc6630 regulator: pwm-regulator: get voltage and duty table from dts
rename st-pwm to pwm-regulator. And support getting voltage & duty table from
device tree, other platforms can also use this driver without any modify.

Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-28 11:35:53 +01:00