Instead of passing a global GPIO number for the enable GPIO, pass
a descriptor looked up from the device tree node for the
regulator.
This regulator supports passing platform data, but enable/sleep
regulators are looked up from the device tree exclusively, so
we can need not touch other files.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
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
...
The config is used for multiple regulators within a for loop. The config
field is not cleared before it is used for the next item. To avoid any
issues this patch adds a proper initialization for the config->ena_gpio
field in case no gpio is available.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch sets ena_gpio_initialized for all drivers which set a
ena_gpio from parsed DT properties. Drivers using pdata may get zero
initialized pdata and therefore copy a 0 into the regulator_config
ena_gpio field.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the tps65090 data manual [0], the DCDC1 and DCDC2
step-down converters and the LDO's have a fixed output voltage.
Add this information to the driver since these fixed regulators
can be used as parent input supply for switches that don't have
an output voltage defined. So the regulator core needs to fetch
the FET parent output voltage if the child voltage is queried.
[0]: http://www.ti.com/lit/gpn/tps65090
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@linaro.org>
The patch (60e91b5 regulator: tps65090: Allow setting the overcurrent
wait time) introduced a crash on Tegra Dalmore. On Dalmore the device
tree doesn't have an entry for all of the FETs so it leaves tps_pdata
NULL in some cases. Add a check for NULL like the rest of the code
does.
Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was plugged in to AC power (when
the backlight voltage was higher).
Mitigate the problem by adding retries on the enables of the FETs,
which works around the problem fairly effectively.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michael Spang <spang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michael Spang <spang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
As per the devicetree binding document of TPS65090, the "regulators"
subnode should be under the parent node, not outside of parent node.
Hence to get the regulator node, the correct call is
of_get_child_by_name() rather than of_find_node_by_name() which searches
the "regulators" node from the parent node to end of DTS file.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The dev parameter is the device requesting the data.
In this case it should be &pdev->dev rather than pdev->dev.parent.
The dev parameter is used to call devm_kzalloc in of_get_regulator_init_data(),
which means this fixes a memory leak because the memory is allocated every time
probe() is called, thus it should be freed when this driver is unloaded.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add DT support for TI PMIC tps65090 regulator driver. The DT of this
device have node regulator and all regulator's node of this device is
added under this node.
The device tree binding document has the required information for
adding this device on DTS file.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This driver can be built as a module, add MODULE_ALIAS for it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The TPS65090's DCDC output can also be enable/disable through the
external digital input signal. Add support for enable/disable
either through register access via I2C or through external
control inputs. The external control inputs can be driven through
GPIOs also and hence adding support for passing the GPIO number.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
TPS65090 supports the two LDOs, LDO1 and LDO2. These are
always ON regulators. The output on these LDOs are available
once the input voltage available for these LDOs.
Add support for these LDOs regulators.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
To make the names proper and more appropriate:
Rename the driver name from tps65090-regulator to tps65090-pmic.
Rename the regulators from TPS65090_ID_* to TPS65090_REGULATOR_*
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
MFD driver registers the regulator driver once per device and
hence it is require to register all regulators in single probe
call.
Following are details of changes done to achieve this:
- Move the regulator enums to mfd header and remove the
tps65090-regulator.h as it does not contain more info.
- Add max regulator and register all regulators even if there
is no regulator init data from platform.
- Convert regulator init data to pointer type in platform data.
- Add input supply name in regulator desc to provide input supply.
- Separate desc information from driver information.
- Disable external control bit to have control through register write.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
All the drivers that need delay for the regulator voltage output voltage to
stabilize after being enabled or after being set to a new value has been
converted to implement enable_time and set_voltage_time_sel callbacks.
Then regulator core will take care of the necessary delay.
For the drivers that don't need the delay, don't need to include linux/delay.h.
This patch removes the unneeded include of linux/delay.h in regulator drivers.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch converts tps65090 regulator driver to use generic regmap
enable/disable operations.
Also move struct tps65090 to include/linux/mfd/tps65090.h because
the regulator driver needs to access the rmap field of struct tps65090.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Venu Byravarasu <vbyravarasu@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Rather than adding new arguments to regulator_register() every time we
want to add a new bit of dynamic information at runtime change the function
to take these via a struct. By doing this we avoid needing to do further
changes like the recent addition of device tree support which required each
regulator driver to be updated to take an additional parameter.
The regulator_desc which should (mostly) be static data is still passed
separately as most drivers are able to configure this statically at build
time.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Both _en_bit and _ops parameters for all DCDCs and FETs are the same, so we
can hardcode it in tps65090_REG macro.
_en_reg can be calculated by _id + 12, so we can also remove it.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked by: Venu Byravarasu <vbyravarasu@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator_register never returns NULL.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked by: Venu Byravarasu <vbyravarasu@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add TPS65090 regulator driver
TPS65090 PMIC from TI consists of 3 step down converters,
2 always on LDOs and 7 current limited load switches. The
output voltages are ON/OFF controllable and are meant to
supply power to the components on target board.
Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
