IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Only the FT SMPS type regulators have slewing supported in the
driver, but all types of SMPS regulators need the same support.
The only difference is that some SMPS regulators don't have a
step size and the step delay is typically 20, not 8. Luckily, the
step size reads as 0 for the non-FT types, so we can always read
that, but we need to detect which type of regulator we're using
to figure out what step delay to use. Make these minor
adjustments to the slew rate calculations and add support for the
delay function to the appropriate regulator ops.
Reported-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 5e3ca2b349b1 ("regulator: Try to resolve regulators supplies on
registration") added a call to regulator_resolve_supply() within
regulator_register() where the regulator_list_mutex is held. This causes
a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC
is registered because regulator_register_resolve_supply() calls
regulator_dev_lookup() which may try to acquire the regulator_list_mutex
again.
Fix this by releasing the mutex before calling
regulator_register_resolve_supply() and update the error exit path to
ensure the mutex is released on an error.
[Made commit message more legible -- broonie]
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Flagging voltage changes as possible for exactly specified voltages
appears to be triggering bugs in the SDHCI code (it should be able to
handle the case where only one voltage it wants is in the range it is
allowed to set) so make sure we only set the flag in cases where there's
genuine variability.
Signed-off-by: Mark Brown <broonie@kernel.org>
This aids in debugging problems triggered by the regulator core applying
its constraints, we could potentially crash immediately after updating
the voltage if the constraints are buggy.
Signed-off-by: Mark Brown <broonie@kernel.org>
This can be used to expose the act8600 registers via debugfs.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This makes the code easier to read and it avoids a dynamic memory
allocation.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Most Maxim PMIC regulator drivers are for sub-devices of Multi-Function
Devices with drivers under drivers/mfd. But for many of these, the same
object file name was used for both the MFD and the regulator drivers.
Having 2 different drivers with the same name causes a lot of confusion
to Kbuild, specially if these are built as module since only one module
will be installed and also exported symbols will be undefined due being
overwritten by the other module during modpost.
For example, it fixes the following issue when both drivers are module:
$ make M=drivers/regulator/
...
CC [M] drivers/regulator//max14577.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "maxim_charger_calc_reg_current" [drivers/regulator//max14577.ko] undefined!
WARNING: "maxim_charger_currents" [drivers/regulator//max14577.ko] undefined!
Reported-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.
Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.
This patch tries to resolve the parent supply for the already registered
regulators each time that a new regulator is registered. So the regulators
that have child regulators marked as always on will be enabled regardless
if a driver gets the child regulator or not.
That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.
Since regulator_resolve_supply() checks for rdev->supply, most of the times
it will be a no-op. Errors aren't checked to keep the possible out of order
dependencies which was the motivation for the mentioned commit.
Also, the supply being available will be enforced on regulator get anyways
in case the resolve fails on regulators registration.
Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org> # 4.1+
On some designs, a handful of the regulators can't be read via
SPMI transactions because they're "secure" and not intended to be
touched by non-secure processors. This driver unconditionally
attempts to read the id registers of all the regulators though,
leading to probe failing and no regulators being registered.
Let's ignore any errors from failing to read the registers and
keep adding other regulators so that this driver can probe on
such devices.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Document the regulators available on pm8994 and add support for
this PMIC to the SPMI PMIC regulator driver.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When machine constraints are applied, regulator framework first sets
initial mode (if any) and then enables the regulator if needed. The current
code in twl4030reg_set_mode always checks if the regulator is enabled
before applying the mode. That results in -EACCES error returned for
"always-on" regulators which have "initial-mode" set in the board DTS. Fix
that by removing the unneeded check.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the TRM, we need to enable i2c access to powerbus before
writing to it. Also, a new write to powerbus should not be attempted if
there is a pending transfer. The current code does not implement that
functionality and while there are no known problems caused by that, it is
better to follow what TRM says.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
instead of 0x1f) thus reading entire register as buck9's voltage. This
effectively caused regulator core to interpret values as higher voltages
than they were and then to set real voltage much lower than intended.
The buck9 provides power to other regulators, including LDO13
and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
voltage caused SD card detection errors on Odroid XU3/XU4:
mmc1: card never left busy state
mmc1: error -110 whilst initialising SD card
During driver probe the regulator core was checking whether initial
voltage matches the constraints. With incorrect vsel_mask of 0xff and
default value of 0x50, the core interpreted this as 5 V which is outside
of constraints (3-3.775 V). Then the regulator core was adjusting the
voltage to match the constraints. With incorrect vsel_mask this new
voltage mapped to a vere low voltage in the driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Currently we only attempt to set the voltage during constraints
application if an exact voltage is specified. Extend this so that if
the currently set voltage for the regulator is outside the bounds set in
constraints we will move the voltage to the nearest constraint, raising
to the minimum or lowering to the maximum as needed. This ensures that
drivers can probe without the hardware being driven out of spec.
Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Apparently due to a wrongly resolved merge conflict between two
branches, which contained the same commit, the commit contents
partially was added two times in a row.
This change reverts the latter wrong inclusion of commit 909f7ee0b5f3
("regulator: core: Add support for active-discharge configuration").
The first applied commit 670666b9e0af ("regulator: core: Add support
for active-discharge configuration") is not touched.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow the core to always use the voltage constraints to set the voltage
on startup. A forthcoming change in that code will ensure that we bring
out of constraints voltages into spec with this setting.
Signed-off-by: Mark Brown <broonie@kernel.org>
The check would dereference pdata, which can be NULL in the non-DT
use case.
Nothing will break if pdata->num_regulators is larger than the number
of regulators that the driver defines: pdata->num_regulators is only
read in act8865_get_init_data() to iterate through pdata->regulators.
The error handler might have some value as a sanity check on the
platform data, but the platform data could be broken in many other
ways that are not checked for (unknown IDs, duplicate IDs), so I see
no reason to perform only this specific check.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The local variable "dev" already contains a pointer to the device,
so there is no need to take the address of "client->dev" again.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_resolve_supply() function checks if a supply has been
associated with a regulator to avoid enabling it if that is not the
case.
But the supply was already looked up with regulator_resolve_supply()
and set with set_supply() before the check and both return on error.
So the fact that this statement has been reached means that neither
of them failed and a supply must be associated with the regulator.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
- Freescale Touch Screen ADC
- X-Powers AXP PMIC with RSB
- TI TPS65086 Power Management IC (PMIC)
- New Device Support
- Supply device PCI IDs for Intel Broxton
- Fix-ups
- Move to clkdev_create() API; intel_quark_i2c_gpio
- Complete re-write of TI's TPS65912 Power Management IC (PMIC)
- Remove unnecessary function argument; axp20x
- Separate out bus related code; axp20x
- Coding Style changes; axp20x
- Allow more drivers to be compiled as modules
- Work around false positive 'used uninitialised' warning; db8500-prcmu
- Bug Fixes
- Remove do_div(); fsl-imx25-gcq
- Fix driver init when built-in; tps65010
- Fix clock-unregister leak; intel-lpss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW6+LJAAoJEFGvii+H/Hdh8kQP/2AKYzPZiw9fhLufsDPvXO5m
BVdLYVyA11oQjQk7/Bh+5Rjz8mR5Tfv4uAJUReC3FOIfC/oJNBfBxYJLDV/P8S0/
KaCEaZrpNmecKrsy+TjmFYtcRa51THAdjlWEUKRks/ZBjwP4YsNnh5reWe+wB7bS
NFbCNhpXFvYXaDGH8MRhKqdChzZkxi+lgOBcFCKvUYO5/o6g/ZRUD/0TXUItJDwh
F8ps5jImHC1imHeRIKWPNrrZqcYasKmObIhvOKMDcwNQPnjrAWq5QuFH4LFhGQ7d
7NMQrBpaGvZyUNBVtL7ZF1xCJ68wAg/ZvZUkKVkax9ubLbSgf6VXYLQEbq+lyFn7
H9A79xPAGN2nC9HsGnCqW0c0qgTOz0DIkbpuaxAGlzBt0zooc19i3cuUd7LX0NG8
ttLaIP1hX6rgvXSFnF0Ihe3iN5A90LTT3ldbn3A8awyS42vEAbUVL9ivRL21BUbB
ilSTO2W05a9HlIVe43o2euytaGvDYX7RbL/g3WcJLF1pA01RCIDQAI5usMpgF3bf
fJ7cszll0OVTTb5UzbfrNsxAn4oNtbwMIspMMFe17pbmxqh+4oomM3CkuTrMVQfB
pA7Uv0jh/mLCV6P52ZEsNiecn0/l0rID8d/DCHjunr2xBWIOrglzZ7n+vLTJMNJ6
72GVBkYRMLbRm+eph1Tp
=gTBA
-----END PGP SIGNATURE-----
Merge tag 'mfd-for-linus-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Drivers:
- Freescale Touch Screen ADC
- X-Powers AXP PMIC with RSB
- TI TPS65086 Power Management IC (PMIC)
New Device Support:
- Supply device PCI IDs for Intel Broxton
Fix-ups:
- Move to clkdev_create() API; intel_quark_i2c_gpio
- Complete re-write of TI's TPS65912 Power Management IC (PMIC)
- Remove unnecessary function argument; axp20x
- Separate out bus related code; axp20x
- Coding Style changes; axp20x
- Allow more drivers to be compiled as modules
- Work around false positive 'used uninitialised' warning; db8500-prcmu
Bug Fixes:
- Remove do_div(); fsl-imx25-gcq
- Fix driver init when built-in; tps65010
- Fix clock-unregister leak; intel-lpss"
* tag 'mfd-for-linus-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (53 commits)
mfd: intel-lpss: Pass I2C configuration via properties on BXT
mfd: imx6sx: Add PCIe register definitions for iomuxc gpr
mfd: ipaq-micro: Use __maybe_unused to hide pm functions
mfd: max77686: Add max77802 to I2C device ID table
mfd: max77686: Export OF module alias information
mfd: max77686: Allow driver to be built as a module
mfd: stmpe: Add the proper PWM resources
mfd: tps65090: Set regmap config reg counts properly
mfd: syscon: Return ENOTSUPP instead of ENOSYS when disabled
mfd: as3711: Set regmap config reg counts properly
mfd: rc5t583: Set regmap config reg counts properly
gpio: tps65086: Add GPO driver for the TPS65086 PMIC
mfd: mt6397: Add platform device ID table
mfd: da9063: Fix missing volatile registers in the core regmap_range volatile lists
mfd: mt6397: Add MT6323 support to MT6397 driver
mfd: mt6397: Add support for different Slave types
mfd: mt6397: int_con and int_status may vary in location
dt-bindings: mfd: Add bindings for the MediaTek MT6323 PMIC
mfd: da9062: Fix missing volatile registers in the core regmap_range volatile lists
mfd: Add documentation for ACT8945A DT bindings
...
Core changes:
- The gpio_chip is now a *real device*. Until now the gpio chips
were just piggybacking the parent device or (gasp) floating in
space outside of the device model. We now finally make GPIO chips
devices. The gpio_chip will create a gpio_device which contains
a struct device, and this gpio_device struct is kept private.
Anything that needs to be kept private from the rest of the kernel
will gradually be moved over to the gpio_device.
- As a result of making the gpio_device a real device, we have added
resource management, so devm_gpiochip_add_data() will cut down on
overhead and reduce code lines. A huge slew of patches convert
almost all drivers in the subsystem to use this.
- Building on making the GPIO a real device, we add the first step
of a new userspace ABI: the GPIO character device. We take small
steps here, so we first add a pure *information* ABI and the tool
"lsgpio" that will list all GPIO devices on the system and all
lines on these devices. We can now discover GPIOs properly from
userspace. We still have not come up with a way to actually *use*
GPIOs from userspace.
- To encourage people to use the character device for the future,
we have it always-enabled when using GPIO. The old sysfs ABI is
still opt-in (and can be used in parallel), but is marked as
deprecated. We will keep it around for the foreseeable future,
but it will not be extended to cover ever more use cases.
Cleanup:
- Bjorn Helgaas removed a whole slew of per-architecture <asm/gpio.h>
includes. This dates back to when GPIO was an opt-in feature and
no shared library even existed: just a header file with proper
prototypes was provided and all semantics were up to the arch to
implement. These patches make the GPIO chip even more a proper
device and cleans out leftovers of the old in-kernel API here
and there. Still some cruft is left but it's very little now.
- There is still some clamping of return values for .get() going
on, but we now return sane values in the vast majority of drivers
and the errorpath is sanitized. Some patches for powerpc, blackfin
and unicore still drop in.
- We continue to switch the ARM, MIPS, blackfin, m68k local GPIO
implementations to use gpiochip_add_data() and cut down on code
lines.
- MPC8xxx is converted to use the generic GPIO helpers.
- ATH79 is converted to use the generic GPIO helpers.
New drivers:
- WinSystems WS16C48
- Acces 104-DIO-48E
- F81866 (a F7188x variant)
- Qoric (a MPC8xxx variant)
- TS-4800
- SPI serializers (pisosr): simple 74xx shift registers connected
to SPI to obtain a dirt-cheap output-only GPIO expander.
- Texas Instruments TPIC2810
- Texas Instruments TPS65218
- Texas Instruments TPS65912
- X-Gene (ARM64) standby GPIO controller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW6m24AAoJEEEQszewGV1zUasP/RpTrjRcNI5QFHjudd2oioDx
R/IljC06Q072ZqVy/MR7QxwhoU8jUnCgKgv4rgMa1OcfHblxC2R1+YBKOUSij831
E+SYmYDYmoMhN7j5Aslr66MXg1rLdFSdCZWemuyNruAK8bx6cTE1AWS8AELQzzTn
Re/CPpCDbujLy0ZK2wJHgr9ZkdcBGICtDRCrOR3Kyjpwk/DSZcruK1PDN+VQMI3k
bJlwgtGenOHINgCq/16edpwj/hzmoJXhTOZXJHI5XVR6czTwb3SvCYACvCkauI/a
/N7b3quG88b5y0OPQPVxp5+VVl9GyVcv5oGzIfTNat/g5QinShZIT4kVV9r0xu6/
TQHh1HlXleh+QI3yX0oRv9ztHreMf+vdpw1dhIwLqHqfJ7AWdOGk7BbKjwCrsOoq
t/qUVFnyvooLpyr53Z5JY8+LqyynHF68G+jUQyHLgTZ0GCE+z+1jqNl1T501n3kv
3CSlNYxSN/YUBN3cnroAIU/ZWcV4YRdxmOtEWP+7xgcdzTE6s/JHb2fuEfVHzWPf
mHWtJGy8U0IR4VSSEln5RtjhRr0PAjTHeTOGAmivUnaIGDziTowyUVF+X5hwC77E
DGTuLVx/Kniv173DK7xNAsUZNAETBa3fQZTgu+RfOpMiM1FZc7tI1rd7K7PjbyCc
d2M0gcq+d11ITJTxC7OM
=9AJ4
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for kernel v4.6. There is quite a
lot of interesting stuff going on.
The patches to other subsystems and arch-wide are ACKed as far as
possible, though I consider things like per-arch <asm/gpio.h> as
essentially a part of the GPIO subsystem so it should not be needed.
Core changes:
- The gpio_chip is now a *real device*. Until now the gpio chips
were just piggybacking the parent device or (gasp) floating in
space outside of the device model.
We now finally make GPIO chips devices. The gpio_chip will create
a gpio_device which contains a struct device, and this gpio_device
struct is kept private. Anything that needs to be kept private
from the rest of the kernel will gradually be moved over to the
gpio_device.
- As a result of making the gpio_device a real device, we have added
resource management, so devm_gpiochip_add_data() will cut down on
overhead and reduce code lines. A huge slew of patches convert
almost all drivers in the subsystem to use this.
- Building on making the GPIO a real device, we add the first step of
a new userspace ABI: the GPIO character device. We take small
steps here, so we first add a pure *information* ABI and the tool
"lsgpio" that will list all GPIO devices on the system and all
lines on these devices.
We can now discover GPIOs properly from userspace. We still have
not come up with a way to actually *use* GPIOs from userspace.
- To encourage people to use the character device for the future, we
have it always-enabled when using GPIO. The old sysfs ABI is still
opt-in (and can be used in parallel), but is marked as deprecated.
We will keep it around for the foreseeable future, but it will not
be extended to cover ever more use cases.
Cleanup:
- Bjorn Helgaas removed a whole slew of per-architecture <asm/gpio.h>
includes.
This dates back to when GPIO was an opt-in feature and no shared
library even existed: just a header file with proper prototypes was
provided and all semantics were up to the arch to implement. These
patches make the GPIO chip even more a proper device and cleans out
leftovers of the old in-kernel API here and there.
Still some cruft is left but it's very little now.
- There is still some clamping of return values for .get() going on,
but we now return sane values in the vast majority of drivers and
the errorpath is sanitized. Some patches for powerpc, blackfin and
unicore still drop in.
- We continue to switch the ARM, MIPS, blackfin, m68k local GPIO
implementations to use gpiochip_add_data() and cut down on code
lines.
- MPC8xxx is converted to use the generic GPIO helpers.
- ATH79 is converted to use the generic GPIO helpers.
New drivers:
- WinSystems WS16C48
- Acces 104-DIO-48E
- F81866 (a F7188x variant)
- Qoric (a MPC8xxx variant)
- TS-4800
- SPI serializers (pisosr): simple 74xx shift registers connected to
SPI to obtain a dirt-cheap output-only GPIO expander.
- Texas Instruments TPIC2810
- Texas Instruments TPS65218
- Texas Instruments TPS65912
- X-Gene (ARM64) standby GPIO controller"
* tag 'gpio-v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (194 commits)
Revert "Share upstreaming patches"
gpio: mcp23s08: Fix clearing of interrupt.
gpiolib: Fix comment referring to gpio_*() in gpiod_*()
gpio: pca953x: Fix pca953x_gpio_set_multiple() on 64-bit
gpio: xgene: Fix kconfig for standby GIPO contoller
gpio: Add generic serializer DT binding
gpio: uapi: use 0xB4 as ioctl() major
gpio: tps65912: fix bad merge
Revert "gpio: lp3943: Drop pin_used and lp3943_gpio_request/lp3943_gpio_free"
gpio: omap: drop dev field from gpio_bank structure
gpio: mpc8xxx: Slightly update the code for better readability
gpio: mpc8xxx: Remove *read_reg and *write_reg from struct mpc8xxx_gpio_chip
gpio: mpc8xxx: Fixup setting gpio direction output
gpio: mcp23s08: Add support for mcp23s18
dt-bindings: gpio: altera: Fix altr,interrupt-type property
gpio: add driver for MEN 16Z127 GPIO controller
gpio: lp3943: Drop pin_used and lp3943_gpio_request/lp3943_gpio_free
gpio: timberdale: Switch to devm_ioremap_resource()
gpio: ts4800: Add IMX51 dependency
gpiolib: rewrite gpiodev_add_to_list
...
At boot time the regulator driver can be initialized before the
gpio, in which case the call to of_get_named_gpio will return
EPROBE_DEFER. This value is silently passed to regulator_register
which will return success, although the gpio is not registered
(regulator_ena_gpio_request not called) as the value passed is
detected as invalid. The gpio_regulator_probe will therefore
succeed win no gpio requested.
Signed-off-by: Mihai Mihalache <mihai.d.mihalache@intel.com>
Reviewed-by: Hans Holmberg <hans.holmberg@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
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>
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>
OF interface provides to read the u32 value via standard interface
of_property_read_u32(). Use this API to read "regulator-min-microvolts"
and "regulator-max-microvolt".
This will make consistent with other property value reads.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch to fix incorrect clear of event register.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch to fix incorrect clear of event register.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator ops callback for configuration of active-discharge
and provide necessarily information via regulator descriptor.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper function to set the state of active-discharge of
regulator using regmap. The HW regulator driver can directly
use this by providing the necessary information in the regulator
descriptor.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The documentation lists both 1.8V and 3.3V for this regulator output,
but 3.3V is mentioned more often and also matches what JZ4770 and
JZ4780 expect as an input.
Note that the voltage of REG9 is not programmable, so this commit only
changes the voltage reported in sysfs and debugfs, not the actual
output voltage of the hardware.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to preserve its value between calls. I guess this
was a copy-paste slip-up.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
These fields are never used and not required at all, remove them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This problem was introduced by:
commit daad134d6649 ("regulator: core: Request GPIO before creating
sysfs entries")
The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.
This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:
[ 1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[ 1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[ 1.130894] pgd = c0004000
[ 1.133598] [00000044] *pgd=00000000
[ 1.137205] Internal error: Oops: 5 [#1] SMP ARM
and here's backtrace from KDB:
Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0: 00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.
Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
