Commit Graph

2933 Commits

Author SHA1 Message Date
Linus Torvalds
6a497e9d58 This is the bulk of GPIO changes for the v4.9 series:
Subsystem improvements:
 
 - Do away with the last users of the obsolete Kconfig options
   ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter
   always sounded like an item on a wishlist to Santa Claus to
   me). We can now select GPIOLIB and be done with it, for all
   archs. After some struggle it even work on UM. Not that it has
   GPIO, but if it wants to, it can select the library.
 
 - Continued efforts to make drivers properly either tristate or
   bool.
 
 - Introduce a warning for drivers assigning default triggers to
   their irqchip lines when probed from device tree, so we find and
   fix these ambigous drivers. It is agreed that in the OF config
   path, the device tree defines trigger characteristics.
 
 - The same warning, mutatis mutandis, for ACPI-probed GPIO
   irqchips.
 
 - We introduce the ability to mark certain IRQ lines as "unusable"
   as they can be taken by BIOS/firmware, unrouted in silicon and
   generally nasty if you use them, and such things. This is
   put to good use in the STMPE driver and also in the Cherryview
   pin control driver.
 
 - A new "mockup" virtual GPIO device that can be used for testing.
   The plan is to add unit tests under tools/* for exercising this
   device and verify that the kernel code paths are working as they
   should.
 
 - Make memory-mapped I/O-drivers depend on HAS_IOMEM. This was
   implicit all the time, but when people started building UM
   with allyesconfig or allmodconfig it exploded in their face.
 
 - Move some stray bits of device tree and ACPI HW description
   callbacks down into their respective implementation silo. These
   were causing issues when compiling on !HAS_IOMEM as well, so
   now eventually UM compiles the GPIOLIB library if it wants to.
 
 New drivers:
 
 - New driver for the Aspeed GPIO front-end companion to the
   pin controller merged through the pin control tree.
 
 - New driver for the LP873x PMIC GPIO portions.
 
 - New driver for Technologic Systems' I2C FPGA GPIO such as
   TS4900, TS-7970, TS-7990 and TS-4100.
 
 - New driver for the Broadcom BCM63xx series including BCM6338
   and BCM6345.
 
 - New driver for the Intel WhiskeyCove PMIC GPIO.
 
 - New driver for the Allwinner AXP209 PMIC GPIO portions.
 
 - New driver for Diamond Systems 48 line GPIO-MM, another of
   these port-mapped I/O expansion cards.
 
 - Support the STMicroelectronics STMPE1600 variant in the STMPE
   driver.
 
 Driver improvements:
 
 - The STMPE driver now supports rising/falling edge detection
   properly for IRQs.
 
 - The PCA954x will now fetch and enable its VCC regulator properly.
 
 - Major rework of the PCA953x driver with the goal of eventually
   switching it over to use regmap and thus modernize it even more.
 
 - Switch the IOP driver to use the generic MMIO GPIO library.
 
 - Move the ages old HTC EGPIO (extended GPIO) GPIO expander driver
   over to this subsystem from MFD, achieveing some separation of
   concerns.
 -----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJX9OvDAAoJEEEQszewGV1zsPQP/3VLy1fNIpMF0DDyq5tA/GNv
 sinnaPgMtt+qBrM2sbJcTVwV9xtHrs12CC3+2lAhBCIEm4YfHbXvaUMNE+aKJzk4
 ZM7/rb8WMUxjQqzDKStdETsQGo6fxh0qU81OEQNbX9alir20jik9DvTufcs6xCgx
 sqh8KsNGO4Y6tiuKZ6mTZvIjVhMwiTm0NBSDKhdim0DdsOcuxyh6xVOj/0LB2Ei6
 g75X1w++wjh0ryY3bzaeWkQSlXDC6eEKeez7VaEkSUyrxH86buomy0+aP0fqs7vY
 LRZzn/TC97YLT6hslS/OhB7uXrDIY2POSwO/SvusJcveGP7WPGyGr5mDtA4ATRWI
 ios0DBWl629kHfhAMzg3kPJS8LfjCerapvtbdAgqvhH+Vb5IPFx45vypDkR2WtJ7
 bNAySIRMQSHZvJSCvYzjqh8AbWdE4i4k70tFXRMOpWeKIvRVI1cDvLD6cLn3hATM
 IPTytM6i2xqnzcq7mK7EJ18afcR0mv1jHgGAv4M0RMkyJ2IrURvFyZIvUB2MTyuL
 PEBh1ZvTs+MO50eeFwzltY91eagkzgWB0f6sm3l7I7bL2oxE2f/WVcVL9jWbgwpF
 otjFO27u0/6rIulfLUQzDo3gbOq7UaN0VTW4E9CYbOtFtNzCxjFIKTv0IJhTu4TT
 OSur7oFpzAMOGYlpYP8j
 =ABbi
 -----END PGP SIGNATURE-----

Merge tag 'gpio-v4.9-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 the v4.9 series:

  Subsystem improvements:

   - do away with the last users of the obsolete Kconfig options
     ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter
     always sounded like an item on a wishlist to Santa Claus to me). We
     can now select GPIOLIB and be done with it, for all archs. After
     some struggle it even work on UM. Not that it has GPIO, but if it
     wants to, it can select the library.

   - continued efforts to make drivers properly either tristate or bool.

   - introduce a warning for drivers assigning default triggers to their
     irqchip lines when probed from device tree, so we find and fix
     these ambigous drivers. It is agreed that in the OF config path,
     the device tree defines trigger characteristics.

   - the same warning, mutatis mutandis, for ACPI-probed GPIO irqchips.

   - we introduce the ability to mark certain IRQ lines as "unusable" as
     they can be taken by BIOS/firmware, unrouted in silicon and
     generally nasty if you use them, and such things. This is put to
     good use in the STMPE driver and also in the Cherryview pin control
     driver.

   - a new "mockup" virtual GPIO device that can be used for testing.
     The plan is to add unit tests under tools/* for exercising this
     device and verify that the kernel code paths are working as they
     should.

   - make memory-mapped I/O-drivers depend on HAS_IOMEM. This was
     implicit all the time, but when people started building UM with
     allyesconfig or allmodconfig it exploded in their face.

   - move some stray bits of device tree and ACPI HW description
     callbacks down into their respective implementation silo. These
     were causing issues when compiling on !HAS_IOMEM as well, so now
     eventually UM compiles the GPIOLIB library if it wants to.

  New drivers:

   - new driver for the Aspeed GPIO front-end companion to the pin
     controller merged through the pin control tree.

   - new driver for the LP873x PMIC GPIO portions.

   - new driver for Technologic Systems' I2C FPGA GPIO such as TS4900,
     TS-7970, TS-7990 and TS-4100.

   - new driver for the Broadcom BCM63xx series including BCM6338 and
     BCM6345.

   - new driver for the Intel WhiskeyCove PMIC GPIO.

   - new driver for the Allwinner AXP209 PMIC GPIO portions.

   - new driver for Diamond Systems 48 line GPIO-MM, another of these
     port-mapped I/O expansion cards.

   - support the STMicroelectronics STMPE1600 variant in the STMPE
     driver.

  Driver improvements:

   - the STMPE driver now supports rising/falling edge detection
     properly for IRQs.

   - the PCA954x will now fetch and enable its VCC regulator properly.

   - major rework of the PCA953x driver with the goal of eventually
     switching it over to use regmap and thus modernize it even more.

   - switch the IOP driver to use the generic MMIO GPIO library.

   - move the ages old HTC EGPIO (extended GPIO) GPIO expander driver
     over to this subsystem from MFD, achieveing some separation of
     concerns"

* tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (81 commits)
  gpio: add missing static inline
  gpio: OF: localize some gpiochip init functions
  gpio: acpi: separation of concerns
  gpio: OF: separation of concerns
  gpio: make memory-mapped drivers depend on HAS_IOMEM
  gpio: stmpe: use BIT() macro
  gpio: stmpe: forbid unused lines to be mapped as IRQs
  mfd/gpio: Move HTC GPIO driver to GPIO subsystem
  gpio: MAINTAINERS: Add an entry for GPIO mockup driver
  gpio/mockup: add virtual gpio device
  gpio: Added zynq specific check for special pins on bank zero
  gpio: axp209: Implement get_direction
  gpio: aspeed: remove redundant return value check
  gpio: loongson1: remove redundant return value check
  ARM: omap2: fix missing include
  gpio: tc3589x: fix up complaints on unsigned
  gpio: tc3589x: add .get_direction() and small cleanup
  gpio: f7188x: use gpiochip_get_data instead of container_of
  gpio: tps65218: use devm_gpiochip_add_data() for gpio registration
  gpio: aspeed: fix return value check in aspeed_gpio_probe()
  ...
2016-10-05 11:49:09 -07:00
Mark Brown
2ed89d577c Merge remote-tracking branch 'regulator/topic/tps80031' into regulator-next 2016-09-30 09:14:02 -07:00
Mark Brown
2dfcb921da Merge remote-tracking branches 'regulator/topic/of', 'regulator/topic/pv88080', 'regulator/topic/rk808', 'regulator/topic/set-voltage' and 'regulator/topic/tps65218' into regulator-next 2016-09-30 09:13:58 -07:00
Mark Brown
81c383c9ba Merge remote-tracking branches 'regulator/topic/bulk', 'regulator/topic/dbx500', 'regulator/topic/hi6421', 'regulator/topic/load' and 'regulator/topic/ltc3676' into regulator-next 2016-09-30 09:13:55 -07:00
Mark Brown
ec09f1c575 Merge remote-tracking branch 'regulator/fix/tps65910' into regulator-linus 2016-09-30 09:13:52 -07:00
Baoyou Xie
5258beedc3 regulator: dbx500: remove unused functions in dbx500-prcmu.c
We get 2 warnings when building kernel with W=1:
drivers/regulator/dbx500-prcmu.c:78:6: warning: no previous prototype for 'ux500_regulator_suspend_debug' [-Wmissing-prototypes]
drivers/regulator/dbx500-prcmu.c:87:6: warning: no previous prototype for 'ux500_regulator_resume_debug' [-Wmissing-prototypes]

In fact, these functions are unused in
dbx500-prcmu.c, but should be removed.

So this patch removes the unused functions.

Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-26 09:40:22 -07:00
Eric Jeong
5ff00f6aa8 regulator: pv88080: Update regulator for PV88080 BB silicon support
Three files are modified, the driver, header file and the binding document.

Updates for the regulator source file include and .of_match_table entry
and node match checking in the probe() function for a compatible pv88080
silicon type. A new "HVBUCK" is added in source file and added
regsiter definition in header file for pv88080 bb silicion.
The binding documentation changes have been made to reflect these updates.

Signed-off-by: Eric Jeong <eric.jeong.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-26 08:59:08 -07:00
Joonwoo Park
577766175c regulator: core: don't return error with inadequate reason
drms_uA_update() always returns failure when it cannot find regulator's
input voltage.  But if hardware supports load configuration with
ops->set_load() and the input regulator isn't specified with valid reason
such as the input regulator is battery, not finding input voltage is
normal so such case should not return with an error.

Avoid such inadequate error return by checking input/output voltages
only when drms_uA_update() is about to configure load with enum based
ops->set_mode().

Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-24 19:36:41 +01:00
Jan Remmet
8f9165c981 regulator: tps65910: Work around silicon erratum SWCZ010
http://www.ti.com/lit/pdf/SWCZ010:
  DCDC o/p voltage can go higher than programmed value

Impact:
VDDI, VDD2, and VIO output programmed voltage level can go higher than
expected or crash, when coming out of PFM to PWM mode or using DVFS.

Description:
When DCDC CLK SYNC bits are 11/01:
* VIO 3-MHz oscillator is the source clock of the digital core and input
  clock of VDD1 and VDD2
* Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant
  phase shift
* Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2)
* The 3 HSD PFET will be turned-on at the same time, causing the highest
  possible switching noise on the application. This noise level depends
  on the layout, the VBAT level, and the load current. The noise level
  increases with improper layout.

When DCDC CLK SYNC bits are 00:
* VIO 3-MHz oscillator is the source clock of digital core
* VDD1 and VDD2 are running on their own 3-MHz oscillator
* Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2)
* The switching noise of the 3 SMPS will be randomly spread over time,
  causing lower overall switching noise.

Workaround:
Set DCDCCTRL_REG[1:0]= 00.

Signed-off-by: Jan Remmet <j.remmet@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2016-09-24 19:04:36 +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
Matthias Kaehlcke
d89564efe7 regulator: core: Don't skip set_voltage_time when ramp delay disabled
The current code assumes that only the ramp_delay is used to determine
the time needed for the voltage to stabilize. This may be true for the
calculation done by regulator_set_voltage_time_sel(), however regulators
can implement their own set_voltage_time_sel() op which would be skipped
if no ramp delay is specified. Remove the check in
_regulator_do_set_voltage(), the functions calculating the ramp delay
return 0 anyway when the ramp delay is not configured.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-16 17:33:40 +01:00
Matthias Kaehlcke
31dfe686ed regulator: core: Simplify error flow in _regulator_do_set_voltage()
If the voltage can not be set jump to the end of the function. This
avoids having to check for an error multiple times and eliminates one
level of nesting in a follow-up change.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-16 17:33:40 +01:00
Matthias Kaehlcke
57995a4860 regulator: core: Use local ops variable in _regulator_do_set_voltage()
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-14 18:12:20 +01:00
Mark Brown
78cefcbe60 Merge remote-tracking branches 'regulator/fix/email' and 'regulator/fix/qcom-smd' into regulator-linus 2016-09-06 12:31:34 +01:00
Baoyou Xie
ea2f7321a9 regulator: hi6421: mark hi6421_regulator_ldo_get_optimum_mode() static
We get 1 warning when building kernel with W=1:
drivers/regulator/hi6421-regulator.c:480:14: warning: no previous prototype for
'hi6421_regulator_ldo_get_optimum_mode' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.

Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-01 20:54:29 +01:00
Keerthy
f618ed218d regulator: lp873x: Change the MFD config option as per latest naming
Change the MFD config option as per latest naming

Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2016-08-31 13:20:44 +01:00
Sebastiaan Schalbroeck
3b063496f0 regulator: Kconfig: Fix typo
Fix typo in regulator Kconfig for the TPS80031 tristate string (trivial)

Signed-off-by: Sebastiaan Schalbroeck <schalbroeck@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-22 17:32:00 +01:00
Krzysztof Kozlowski
cea8aa3a93 regulator: Change Krzysztof Kozlowski's email to kernel.org
Change my email address to kernel.org instead of Samsung one for the
purpose of any future contact.  The copyrights remain untouched and are
attributed to Samsung.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-17 13:41:14 +01:00
Bjorn Andersson
565f9b073f regulator: Remove support for optional supplies in the bulk API
The patch was based on my missinterpretation of the API and only
accidentally worked for me. Let's clean it out to not confuse others.

This reverts commit 3ff3f518a1.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-16 20:00:44 +01:00
Tim Harvey
37b918a034 regulator: Add LTC3676 support
This patch adds support for the Linear Technology LTC3676
8-output I2C voltage regulator IC.

Cc: Jaffer Kapasi <jkapasi@linear.com>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-16 12:28:00 +01:00
Markus Elfring
556ae220ac regulator: rk808: Delete owner assignment
The field "owner" is set by core. Thus delete an extra initialisation.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-15 13:46:55 +01:00
Tero Kristo
23a34f9d03 regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-10 18:21:55 +01:00
Linus Torvalds
a157b3aaa4 pwm: Changes for v4.8-rc1
This set of changes improve some aspects of the atomic API as well as
 make use of this new API in the regulator framework to allow properly
 dealing with critical regulators controlled by a PWM.
 
 Aside from that there's a bunch of updates and cleanups for existing
 drivers, as well as the addition of new drivers for the Broadcom iProc,
 STMPE and ChromeOS EC controllers.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQI2BAABCAAgBQJXpLFKGRx0aGllcnJ5LnJlZGluZ0BnbWFpbC5jb20ACgkQ3SOs
 138+s6E2Nw/9FggtgYlVQRS5lzwTKxQI/5HMlOfdyH84S76fUS8uAxvEsZvyHXZ7
 NiwCJMkmMqPHMlrfuXacs4nueKz3jvy8csaffH5T2yHf0ZPGmkxBsdX97rvQp3z/
 WTUXX8vo8fiEPQSXQOUzIYk10s7CBO2094uL8FBqfYeSySY3Ti35SpmZSQKVd1LS
 A1rR/qRgNbIlhI7+L5CotdrNMkHXqHZIHDyXO1dWBDVL+3MU3IPpB//J/WjU/OMs
 5MHEtTr7943s8LQYhM1p5PFDn8ehe31L1quSswmMTLuepPrTUjD31476VYW8p8gg
 lzOv5JF5b8Rkw0B+4vDC0z/OPZA47tg8DfiS9Sa1SrCGxslOH7pvI7m9dV89FOc2
 /hA1n048jBhIrHPylXZ+hUPKNM0WTwFrHVxROgtEb6/wtYskgOFGQrYKpD4FtH+j
 zqXxvCRMX4ZLLXy2QO4GAW3dv51pLjiM2yxVWtM1lWFWiKKvRoqHiFcnmCJJwQ4T
 NXUPnyt+G/GCtpVHlMtHW9YszJ650ECt+H8I1EhuGLkpOXncCPdmw34oR1wSmMi3
 +1yjCvZV8bNJLt2GQDpoFEUc1dqY6g/SLqm9sz+W69QYA0oDt9JpFK+RFw118282
 EX24GT9+PYe0kMt1WWopjHeFZ+6HhsG/ODwOUOaG/8kp6qZLB4EKP9k=
 =TdEI
 -----END PGP SIGNATURE-----

Merge tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

Pull pwm updates from Thierry Reding:
 "This set of changes improve some aspects of the atomic API as well as
  make use of this new API in the regulator framework to allow properly
  dealing with critical regulators controlled by a PWM.

  Aside from that there's a bunch of updates and cleanups for existing
  drivers, as well as the addition of new drivers for the Broadcom
  iProc, STMPE and ChromeOS EC controllers"

* tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
  regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range
  regulator: pwm: Support extra continuous mode cases
  pwm: Add ChromeOS EC PWM driver
  dt-bindings: pwm: Add binding for ChromeOS EC PWM
  mfd: cros_ec: Add EC_PWM function definitions
  mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper
  pwm: atmel: Use of_device_get_match_data()
  pwm: atmel: Fix checkpatch warnings
  pwm: atmel: Fix disabling of PWM channels
  dt-bindings: pwm: Add R-Car H3 device tree bindings
  pwm: rcar: Use ARCH_RENESAS
  pwm: tegra: Add support for Tegra186
  dt-bindings: pwm: tegra: Add compatible string for Tegra186
  pwm: tegra: Avoid overflow when calculating duty cycle
  pwm: tegra: Allow 100 % duty cycle
  pwm: tegra: Add support for reset control
  pwm: tegra: Rename mmio_base to regs
  pwm: tegra: Remove useless padding
  pwm: tegra: Drop NUM_PWM macro
  pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value
  ...
2016-08-06 00:01:33 -04:00
Stephen Boyd
c488f0071e regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo
The voltage ranges listed here are wrong. The pma8084 pldo
supports three different overlapping voltage ranges with
differing step sizes and the pma8084 ftsmps supports two. These
ranges can be seen in the "native" spmi regulator driver
(qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
respectively. Port these ranges over to the RPM SMD regulator
driver so that we list the appropriate set of supported voltages
on these types of regulators.

Fixes: ee01d0c91e ("regulator: qcom-smd: Add support for PMA8084")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-05 12:51:51 +01:00
Stephen Boyd
290284776b regulator: qcom_smd: Fix voltage ranges for pm8x41
The voltage ranges listed here are wrong. The correct ranges can
be seen in the "native" spmi regulator driver
qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and
boost_ranges[] for the pldo, ftsmps, and boost type regulators.
Port these ranges over to the RPM SMD regulator driver so that we
list the appropriate set of supported voltages on pldos.

Doing this allows us to specify a voltage like 3075000 for l24,
whereas before that wasn't a supported voltage.

Fixes: da65e367b6 ("regulator: Regulator driver for the Qualcomm RPM")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-05 12:51:42 +01:00
Linus Torvalds
43a0a98aa8 ARM: SoC driver updates for v4.8
Driver updates for ARM SoCs.
 
 A slew of changes this release cycle. The reset driver tree, that we merge
 through arm-soc for historical reasons, is also sizable this time around.
 
 Among the changes:
 
  - clps711x: Treewide changes to compatible strings, merged here for simplicity.
  - Qualcomm: SCM firmware driver cleanups, move to platform driver
  - ux500: Major cleanups, removal of old mach-specific infrastructure.
  - Atmel external bus memory driver
  - Move of brcmstb platform to the rest of bcm
  - PMC driver updates for tegra, various fixes and improvements
  - Samsung platform driver updates to support 64-bit Exynos platforms
  - Reset controller cleanups moving to devm_reset_controller_register() APIs
  - Reset controller driver for Amlogic Meson
  - Reset controller driver for Hisilicon hi6220
  - ARM SCPI power domain support
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJXnm1XAAoJEIwa5zzehBx35lcP/ApuQarIXeZCQZtjlUBV9McW
 o3o7FhKFHePmEPeoYCvVeK5D8NykTkQv3WpnCknoxPJzxGJF7jbPWQJcVnXfKOXD
 kTcyIK15WL2HHtSE3lYyLfyUPz8AbJyRt0l0cxgcg6jvo+uzlWooNz1y78rLIYzg
 UwRssj7OiHv4dsyYRHZIsjnB8gMWw8rYMk154gP2xy6MnNXXzzOVVnOiVqxSZBm+
 EgIIcROMOqkkHuFlClMYKluIgrmgz1Ypjf+FuAg7dqXZd+TGRrmGXeI7SkGThfLu
 nyvY3N18NViNu7xOUkI9zg7+ifyYM8Si9ylalSICSJdIAxZfiwFqFaLJvVWKU1rY
 rBOBjKckQI0/X9WYusFNFHcijhIFV8/FgGAnVRRMPdvlCss7Zp03C9mR4AEhmKMX
 rLG49x81hU1C+LftC59ml3iB8dhZrrRkbxNHjLFHVGWNrKMrmJKa8JhXGRAoNM+u
 LRauiuJZatqvLfISNvpfcoW2EashVoU3f+uC8ymT3QCyME3wZm0t7T4tllxhMfBl
 sOgJqNkTKDmPLofwm/dASiLML7ZF1WePScrFyOACnj9K4mUD+OaCnowtWoQPu0eI
 aNmT84oosJ2S9F/iUDPtFHXdzQ+1QPPfSiQ9FXMoauciVq/2F+pqq68yYgqoxFOG
 vmkmG2YM4Wyq43u0BONR
 =O8+y
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC driver updates from Olof Johansson:
 "Driver updates for ARM SoCs.

  A slew of changes this release cycle.  The reset driver tree, that we
  merge through arm-soc for historical reasons, is also sizable this
  time around.

  Among the changes:

   - clps711x: Treewide changes to compatible strings, merged here for simplicity.
   - Qualcomm: SCM firmware driver cleanups, move to platform driver
   - ux500: Major cleanups, removal of old mach-specific infrastructure.
   - Atmel external bus memory driver
   - Move of brcmstb platform to the rest of bcm
   - PMC driver updates for tegra, various fixes and improvements
   - Samsung platform driver updates to support 64-bit Exynos platforms
   - Reset controller cleanups moving to devm_reset_controller_register() APIs
   - Reset controller driver for Amlogic Meson
   - Reset controller driver for Hisilicon hi6220
   - ARM SCPI power domain support"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (100 commits)
  ARM: ux500: consolidate base platform files
  ARM: ux500: move soc_id driver to drivers/soc
  ARM: ux500: call ux500_setup_id later
  ARM: ux500: consolidate soc_device code in id.c
  ARM: ux500: remove cpu_is_u* helpers
  ARM: ux500: use CLK_OF_DECLARE()
  ARM: ux500: move l2x0 init to .init_irq
  mfd: db8500 stop passing around platform data
  ASoC: ab8500-codec: remove platform data based probe
  ARM: ux500: move ab8500_regulator_plat_data into driver
  ARM: ux500: remove unused regulator data
  soc: raspberrypi-power: add CONFIG_OF dependency
  firmware: scpi: add CONFIG_OF dependency
  video: clps711x-fb: Changing the compatibility string to match with the smallest supported chip
  input: clps711x-keypad: Changing the compatibility string to match with the smallest supported chip
  pwm: clps711x: Changing the compatibility string to match with the smallest supported chip
  serial: clps711x: Changing the compatibility string to match with the smallest supported chip
  irqchip: clps711x: Changing the compatibility string to match with the smallest supported chip
  clocksource: clps711x: Changing the compatibility string to match with the smallest supported chip
  clk: clps711x: Changing the compatibility string to match with the smallest supported chip
  ...
2016-08-01 18:36:01 -04: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
Mark Brown
a485f5fc8c Merge remote-tracking branches 'regulator/topic/qcom-spmi', 'regulator/topic/rn5t618', 'regulator/topic/tps65218' and 'regulator/topic/twl' into regulator-next 2016-07-20 18:02:08 +01:00
Mark Brown
5f1aa35074 Merge remote-tracking branches 'regulator/topic/mt6397', 'regulator/topic/of', 'regulator/topic/pfuze100', 'regulator/topic/pwm' and 'regulator/topic/qcom-smd' into regulator-next 2016-07-20 18:02:06 +01:00
Mark Brown
eb58e90bf0 Merge remote-tracking branches 'regulator/topic/fixed', 'regulator/topic/headers', 'regulator/topic/lp837x', 'regulator/topic/max8973' and 'regulator/topic/mt6323' into regulator-next 2016-07-20 18:02:03 +01:00
Mark Brown
5fea0902ea Merge remote-tracking branches 'regulator/topic/act8865', 'regulator/topic/can-change-voltage', 'regulator/topic/da9210' and 'regulator/topic/da9211' into regulator-next 2016-07-20 18:02:01 +01:00
Mark Brown
38cdaddf56 Merge remote-tracking branch 'regulator/topic/axp20x' into regulator-next 2016-07-20 18:02:01 +01:00
Mark Brown
02214f1061 Merge remote-tracking branches 'regulator/fix/da9053' and 'regulator/fix/s2mps11' into regulator-linus 2016-07-20 18:01:59 +01:00
Steve Twiss
707319b60a regulator: da9053/52: Fix incorrectly stated minimum and maximum voltage limits
This fix alters the minimum and maximum BUCK voltage limits for DA9052 and
DA9053. It does so for the following cases:

DA9052
- BUCK3 (MEM)
   min: 0.925V -> 0.950V
   max: 2.500V -> 2.525V

DA9053
- BUCK3 (MEM)
   min: 0.925V -> 0.950V
   max: 2.500V -> 2.525V
- BUCK4 (PERI)
   min: 0.925V -> 0.950V
   max: 2.500V -> 2.525V

The voltage range remains the same, but the limits are shifted by +0.025V.

This change is provided on DA9052:MEM, DA9053:MEM and DA9053:PERI
and is a voltage difference of 0.025V, compared to those measured before
this fix is applied. The patch has the effect of decreasing *all* measured
voltages on those BUCKs when compared against the previously measured
values for the same software voltage request.

For example, with this fix applied for DA9052:MEM, DA9053:MEM and
DA9053:PERI, the following is true.

Because the previous software defined slot 0 as being 0.925V, if a request
for 0.950V was previously sent, the slot 1 voltage would have been used.
This would have corresponded to an actual measured voltage of 0.975V. But,
with this patch fix, and with slot 0 properly aligned to 0.950V, if a
voltage of 0.950V is requested by software, a measured value of 0.950V will
be provided.

Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-20 17:00:34 +01:00
Axel Lin
634f41dcec regulator: mt6323: Constify struct regulator_ops
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-19 18:31:59 +01:00
Axel Lin
15b1dc9823 regulator: mt6323: Fix module description
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-19 18:31:59 +01:00
Chen Zhong
2fdf829236 regulator: mt6323: Add support for MT6323 regulator
The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong <chen.zhong@mediatek.com>
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-18 13:46:23 +01:00
Steve Twiss
2d0cf04ce1 regulator: da9210: addition of device tree support
Addition of device tree support for DA9210.
Two files are modified, the driver source file and the binding document.

Updates for the regulator source file include an .of_match_table entry and
node match checking in the probe() function for a compatible da9210 string.

Minor binding documentation changes have been made to the title and the
example.

Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-15 11:45:26 +01:00
Wei Yongjun
842a882427 regulator: act8865: Fix missing of_node_put() in act8865_pdata_from_dt()
This node pointer is returned by of_get_child_by_name() with
refcount incremented in this function. of_node_put() is missing
when exitting this function while invalid device type. Fix it
by move of_get_child_by_name() code after device type check.

Found by Coccinelle.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-14 17:22:22 +01:00
Arnd Bergmann
79886be097 ARM: ux500: move ab8500_regulator_plat_data into driver
There is only one instance of ab8500_regulator_platform_data, and it's
safe to assume we won't ever merge another one, so it's rather pointless
to pass it through multiple levels of platform data pointers.

This moves the structure and everything referenced by it into the
driver that uses it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-12 11:23:50 +02:00
Stephen Boyd
b7a8524cfa regulator: qcom_smd: Avoid overlapping linear voltage ranges
The pm8x41_hfsmps ranges overlap. The first range is from 375000
to 1562500:

 375000 + (95 * 12500) == 1562500

and the second range starts at 1550000. Interestingly, the second
range ends at the correct value when it's set to be the
appropriate start value, 1575000:

 1575000 + ((158 - 96) * 25000) == 3125000

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-12 10:01:36 +01:00
Alim Akhtar
04c16b84e4 regulator: s2mps11: Fix the voltage linear range for s2mps15
This patch fixes some of the LDOs and BUCKs voltage range as per
user manual of s2mps15 (REV0.4).

Fixes: 51af206758 ("regulator: s2mps11: Add support for S2MPS15 regulators")
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
2016-07-12 09:24:05 +01: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
Mark Brown
a29a36f265 Merge remote-tracking branches 'regulator/fix/anatop' and 'regulator/fix/max77620' into regulator-linus 2016-07-01 18:06:48 +02:00
Venkat Reddy Talla
91ff811f32 regulator: max77620: check for valid regulator info
SD4 regulator is not registered with regulator core
framework in probe as there is no support in MAX77620 PMIC,
removing SD4 entry from MAX77620 regulator information list
and checking for valid regulator information data before
configuring FPS source and FPS power up/down period to avoid
NULL pointer exception if regulator not registered with core.

Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-29 18:50:05 +01:00
James Ban
7524c1cebc regulator: da9211: add descriptions for da9212/da9214
This is a patch for adding description for da9212/da9214.

Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-29 17:24:55 +01:00