aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/regulator (follow)
AgeCommit message (Collapse)AuthorFilesLines
2012-09-28Merge remote-tracking branches 'regulator/topic/core', 'regulator/topic/bypass', 'regulator/topic/tol', 'regulator/topic/drivers' and 'regulator/topic/tps6586x' into regulator-nextMark Brown4-1/+94
2012-09-10regulator: core: Provide regmap get/set bypass operationsMark Brown1-0/+4
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-09-10regulator: core: Support bypass modeMark Brown3-0/+20
Many regulators support a bypass mode where they simply switch their input supply to the output. This is mainly used in low power retention states where power consumption is extremely low so higher voltage or less clean supplies can be used. Support this by providing ops for the drivers and a consumer API which allows the device to be put into bypass mode if all consumers enable it and the machine enables permission for this. This is not supported as a mode since the existing modes are rarely used due to fuzzy definition and mostly redundant with modern hardware which is able to respond promptly to load changes. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Graeme Gregory <gg@slimlogic.co.uk>
2012-09-10regulator: Fairchild fan53555 supportYunfan Zhang1-0/+60
This driver supports Fairchild FAN53555 Digitally Programmable TinyBuck Regulator. The FAN53555 is a step-down switching voltage regulator that delivers a digitally programmable output from an input voltage supply of 2.5V to 5.5V. The output voltage is programmed through an I2C interface. Signed-off-by: Yunfan Zhang <yfzhang@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-31regulator: Clarify documentation for regmap in the configMark Brown1-1/+2
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-28regulator: Update comment for set_current_limit callback of struct regulator_opsAxel Lin1-0/+1
The regulators should be tending to the maximum in the available range and consumers should specify the widest range possible. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-08regulator: add a new API regulator_set_voltage_tol()Shawn Guo1-0/+7
There are some use cases where a voltage range could be reasonably specified by a target voltage and tolerance. Add a new API regulator_set_voltage_tol() wrapping regulator_set_voltage() call to ease the users. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-22Merge branch 'regulator-drivers' into regulator-nextMark Brown4-0/+118
2012-07-22Merge branches 'regulator-core', 'regulator-dt' and 'regulator-dummy' into regulator-nextMark Brown1-4/+7
2012-07-12regulator: Add REGULATOR_STATUS_UNDEFINED.Krystian Garbaciak1-0/+2
REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state doesn't really apply. Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-05regulator: fixed: dt: support for input supplyLaxman Dewangan1-0/+2
Add support for input supply in DT parsing of node. The input supply will be provided by the property "vin-supply" in the regulator node. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-03regulator: core: Add core support for GPIO controlled enable linesMark Brown1-0/+11
It is very common for regulators to support having their enable signal controlled by a GPIO. Since there are a bunch of fiddly things to get right like handling the operations when the enable signal is tied to a rail and it's just replicated code add support for this to the core. Drivers should set ena_gpio in their config if they have a GPIO control, using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for the initial state) and ena_gpio_invert if the GPIO is active low. The core will then override any enable and disable operations the driver has and instead control the specified GPIO. This will in the future also allow us to further extend the core by identifying when several enable signals have been tied together and handling this properly. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-03regulator: core: Allow fixed enable_time to be set in the regulator_descMark Brown1-0/+4
Many regulators have a fixed specification for their enable time. Allow this to be set in the regulator_desc as a number to save them having to implement an explicit operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-01regulator: add missing defintion regulator_is_supported_voltagePhilip Rakity1-0/+6
This definition is missing when CONFIG_REGULATOR is not defined. This causes compiler errors when compiling sdhci.c. This can be worked around by adding #ifdef CONFIG_REGULATOR .. #endif but since other definitions are there we have defined the missing definition Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-19regulator: extend the fixed dummy voltage regulator to accept voltageGuennadi Liakhovetski1-3/+3
Trivially extend the regulator_register_always_on() helper function to be even more useful by adding a voltage parameter to it. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-19regulator: support multiple dummy fixed regulatorsGuennadi Liakhovetski1-2/+5
Currently regulator_register_fixed() uses a constant name to register a fixed dummy regulator. This is sufficient in principle, since there is no reason to register multiple such regulators. The user can simply supply all consumers in one array and use it to initialise such a regulator. However, in some cases it can be convenient to register multiple such regulators. This is also a prerequisite for the upcoming patch, that will add a voltage parameter to this function. The original function is provided as a wrapper macro. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-19regulator: add new regulator driver for lp872xKim, Milo1-0/+90
This driver supports TI/National LP8720, LP8725 PMIC. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-18regulator: stubs: Make stub regulator_get_voltage() return an errorMark Brown1-1/+1
Returning 0 isn't useful, it's not even meaningful if there is a real regulator there. Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-18regulator: core: Change the unit of ramp_delay from mV/uS to uV/uSAxel Lin2-2/+2
This change makes it possible to set ramp_delay with 0.xxx mV/uS without truncation issue. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-17regulator: Add ramp_delay configuration to constraintsYadwinder Singh Brar2-0/+6
For some hardwares ramp_delay for BUCKs is a configurable parameter which can be configured through DT or board file.This patch adds ramp_delay to regulator constraints and allow user to configure it for regulators which supports this feature, through DT or board file. It will provide two ways of setting the ramp_delay for a regulator: First, by setting it as constraints in board file(for configurable regulators) and set_machine_constraints() will take care of setting it on hardware by calling(the provided) .set_ramp_delay() operation(callback). Second, by setting it as data in regulator_desc(as fixed/default ramp_delay rate) for a regulator in driver. regulator_set_voltage_time_sel() will give preference to constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly users should also take care accordingly while refering ramp_delay rate(in case of implementing their private .set_voltage_time_sel() callbacks for different regulators). [Rewrote subject for 80 columns -- broonie] Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-11regulator: core: Add regulator_set_voltage_time_sel to calculate ramp delay.Yadwinder Singh Brar1-0/+5
This patch adds regulator_set_voltage_time_sel(), to move into core, the commonly used code by drivers to provide the .set_voltage_time_sel callback. It will also allow us to configure different ramp delay for different regulators easily. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-03regulator: core: Allow drivers to set voltage mapping table in regulator_descAxel Lin1-0/+5
Some regulator hardware use table based mapping can set volt_table in regulator_desc and use regulator_list_voltage_table() for their list_voltage callback. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-14regulator: tps62360: support force PWM mode via regulator modeLaxman Dewangan1-2/+0
Change the mechanism of enabling the force PWM mode through regulator set mode. This can be dynamically configured now. In the REGULATOR_MODE_FAST the force PWM is enabled and in REGULATOR_MODE_NORMAL the force PWM is disabled. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-13regulator: tps62360: make init_data of platform data to pointer.Laxman Dewangan1-3/+1
Convert platform data member regulator_init_data to pointer type. This will avoid the copy of entire regualator init data into platform data member when adding dt support and it can be achieve by simple assignment: pdata->init_data = of_get_regulator_init_data(dev, dev->of_node); Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-12regulator: core: Allow drivers to set simple linear voltage maps as dataMark Brown1-2/+13
A lot of regulator hardware maps selectors on to voltages with a simple linear mapping function selector = base + (selector * step size) Provide off the shelf list_voltage() and map_voltage() operations which use new min_uV and uV_step members in the regulator_desc to implement this function. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
2012-05-12regulator: core: Allow regulators to provide a voltage to selector mappingMark Brown1-0/+4
In order to allow more drivers to factor things out into data allow drivers to provide a mapping function to convert voltages into selectors. This allows any driver to use set_voltage_sel(). The existing mapping based on iterating over list_voltage() is provided as an operation which can be assigned to the new map_voltage() function though for ease of transition it is treated as the default. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
2012-05-12Merge remote-tracking branch 'regulator/topic/drivers' into regulator-nextMark Brown1-0/+18
Conflicts: drivers/regulator/88pm8607.c (simple overlap with a bugfix in v3.4)
2012-05-04regulator: Add generic DT parsing for regulatorsThierry Reding1-0/+18
Looking up init data for regulators found on chips is a common operation that can be handled in a generic way. The new helper function introduced by this patch looks up the children of a given node by names specified in a match table and fills that match table with information parsed from the DT. This is based on work by Rhyland Klein <rklein@nvidia.com>. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-16regulator: core: Provide standard enable operations for regmap usersMark Brown1-0/+7
Since the enable(), disable() and is_enabled() operations for most regmap based regulators come down to reading and updating a single register bit we can factor out the code and allow these drivers to just define which bit to update using the enable_reg and enable_mask fields in their desc and then use operations provided by the core. As well as the code saving this opens the door to future optimisation of the bulk operations - if the core can realise that we are updating a single register for multiple regulators then it should be able to combine these updates into a single physical operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
2012-04-16regulator: core: Provide regmap based voltage_sel operationsMark Brown1-0/+9
Since the voltage selector operations are intended to directly map a bitfield in the device register map into regulator API operations the code for implementing them is usually very standard we can save some code by providing standard implementations for devices using the regmap API. Drivers using regmap can pass their regmap in in the regmap_config struct, set vsel_reg and vsel_mask in their regulator_desc and then use regulator_{get,set}_voltage_sel_regmap in their ops. This saves a small amount of code from each driver. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
2012-04-16regulator: core: Allow drivers to pass in a regmapMark Brown1-0/+4
Since many regulators use regmap for register I/O and since there's quite a few very common patterns in the code allow drivers to pass in a regmap to the core for use in generic code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
2012-04-10Merge tag 'v3.4-rc2' into regulator-driversMark Brown1-5/+3
Linux 3.4-rc2 contains some fixes that further patches depend upon.
2012-04-09regulator: core: Use a struct to pass in regulator runtime configurationMark Brown1-5/+26
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>
2012-04-09Merge branch 'regulator-register' into regulator-driversMark Brown1-2/+3
2012-04-04Merge tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulatorLinus Torvalds1-5/+3
Pull regulator fixes from Mark Brown: "A bunch of smallish fixes that came up during the merge window as things got more testing - even more fixes from Axel, a fix for error handling in more complex systems using -EPROBE_DEFER and a couple of small fixes for the new dummy regulators." * tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: Remove non-existent parameter from fixed-helper.c kernel doc regulator: Fix setting new voltage in s5m8767_set_voltage regulator: fix sysfs name collision between dummy and fixed dummy regulator regulator: Fix deadlock on removal of regulators with supplies regulator: Fix comments in include/linux/regulator/machine.h regulator: Only update [LDOx|DCx]_HIB_MODE bits in wm8350_[ldo|dcdc]_set_suspend_disable regulator: Fix setting low power mode for wm831x aldo regulator: Return microamps in wm8350_isink_get_current regulator: wm8350: Fix the logic to choose best current limit setting regulator: wm831x-isink: Fix the logic to choose best current limit setting regulator: wm831x-dcdc: Fix the logic to choose best current limit setting regulator: anatop: patching to device-tree property "reg". regulator: Do proper shift to set correct bit for DC[2|5]_HIB_MODE setting regulator: Fix restoring pmic.dcdcx_hib_mode settings in wm8350_dcdc_set_suspend_enable regulator: Fix unbalanced lock/unlock in mc13892_regulator_probe error path regulator: Fix set and get current limit for wm831x_buckv regulator: tps6586x: Fix list minimal voltage setting for LDO0
2012-04-04regulator: core: Constify the regulator_desc passed in when registeringMark Brown1-2/+3
Drivers should be able to declare their descriptors const and the framework shouldn't ever be modifying the desciptor. Make the parameter and the pointer in regulator_dev const to enforce this. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-02regulator: fixed: Support for open drain gpio pinLaxman Dewangan1-0/+7
Adding flag on fixed regulator board configuration structure to specify whether gpio is open drain type or not. Passing this information to gpio library when requesting gpio so that gpio driver can set the pin state accordingly, for open drain type: - Pin can be set HIGH as setting as input, PULL UP on pin make this as HIGH. - Pin can be set LOW as setting it as output and drive to LOW. The non-open drain pin can be set HIGH/LOW by setting it to output and driving it to HIGH/LOW. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-01regulator: Add TPS65090 regulator driverVenu Byravarasu1-0/+50
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>
2012-03-29regulator: Fix comments in include/linux/regulator/machine.hAxel Lin1-5/+3
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-28Merge tag 'mfd_3.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6Linus Torvalds1-1/+69
Pull MFD changes from Samuel Ortiz: - 4 new drivers: Freescale i.MX on-chip Anatop, Ricoh's RC5T583 and TI's TPS65090 and TPS65217. - New variants support (8420, 8520 ab9540), cleanups and bug fixes for the abx500 and db8500 ST-E chipsets. - Some minor fixes and update for the wm8994 from Mark. - The beginning of a long term TWL cleanup effort coming from the TI folks. - Various fixes and cleanups for the s5m, TPS659xx, pm860x, and MAX8997 drivers. Fix up trivial conflicts due to duplicate patches and header file cleanups (<linux/device.h> removal etc). * tag 'mfd_3.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: (97 commits) gpio/twl: Add DT support to gpio-twl4030 driver gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ support mfd: Detach twl6040 from the pmic mfd driver mfd: Replace twl-* pr_ macros by the dev_ equivalent and do various cleanups mfd: Micro-optimization on twl4030 IRQ handler mfd: Make twl4030 SIH SPARSE_IRQ capable mfd: Move twl-core IRQ allocation into twl[4030|6030]-irq files mfd: Remove references already defineid in header file from twl-core mfd: Remove unneeded header from twl-core mfd: Make twl-core not depend on pdata->irq_base/end ARM: OMAP2+: board-omap4-*: Do not use anymore TWL6030_IRQ_BASE in board files mfd: Return twl6030_mmc_card_detect IRQ for board setup Revert "mfd: Add platform data for MAX8997 haptic driver" mfd: Add support for TPS65090 mfd: Add some da9052-i2c section annotations mfd: Build rtc5t583 only if I2C config is selected to y. mfd: Add anatop mfd driver mfd: Fix compilation error in tps65910.h mfd: Add 8420 variant to db8500-prcmu mfd: Add 8520 PRCMU variant to db8500-prcmu ...
2012-03-27Merge tag 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds1-24/+0
Pull "ARM: driver specific updates" from Arnd Bergmann: "These are all specific to some driver. They are typically the platform side of a change in the drivers directory, such as adding a new driver or extending the interface to the platform. In cases where there is no maintainer for the driver, or the maintainer prefers to have the platform changes in the same branch as the driver changes, the patches to the drivers are included as well. A much smaller set of driver updates that depend on other branches getting merged first will be sent later. The new export of tegra_chip_uid conflicts with other changes in fuse.c. In rtc-sa1100.c, the global removal of IRQF_DISABLED conflicts with the cleanup of the interrupt handling of that driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de>" Fixed up aforementioned trivial conflicts. * tag 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (94 commits) ARM: SAMSUNG: change the name from s3c-sdhci to exynos4-sdhci mmc: sdhci-s3c: add platform data for the second capability ARM: SAMSUNG: support the second capability for samsung-soc ARM: EXYNOS: add support DMA for EXYNOS4X12 SoC ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1 ARM: EXYNOS: Enable MDMA driver regulator: Remove bq24022 regulator driver rtc: sa1100: add OF support pxa: magician/hx4700: Convert to gpio-regulator from bq24022 ARM: OMAP3+: SmartReflex: fix error handling ARM: OMAP3+: SmartReflex: fix the use of debugfs_create_* API ARM: OMAP3+: SmartReflex: micro-optimization for sanity check ARM: OMAP3+: SmartReflex: misc cleanups ARM: OMAP3+: SmartReflex: move late_initcall() closer to its argument ARM: OMAP3+: SmartReflex: add missing platform_set_drvdata() ARM: OMAP3+: hwmod: add SmartReflex IRQs ARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need ARM: OMAP3+: SmartReflex: Fix status masking in ERRCONFIG register ARM: OMAP3+: SmartReflex: Add a shutdown hook ARM: OMAP3+: SmartReflex Class3: disable errorgen before disable VP ... Conflicts: arch/arm/mach-tegra/Makefile arch/arm/mach-tegra/fuse.c drivers/rtc/rtc-sa1100.c
2012-03-24Merge tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linuxLinus Torvalds1-1/+2
Pull <linux/device.h> avoidance patches from Paul Gortmaker: "Nearly every subsystem has some kind of header with a proto like: void foo(struct device *dev); and yet there is no reason for most of these guys to care about the sub fields within the device struct. This allows us to significantly reduce the scope of headers including headers. For this instance, a reduction of about 40% is achieved by replacing the include with the simple fact that the device is some kind of a struct. Unlike the much larger module.h cleanup, this one is simply two commits. One to fix the implicit <linux/device.h> users, and then one to delete the device.h includes from the linux/include/ dir wherever possible." * tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: device.h: audit and cleanup users in main include dir device.h: cleanup users outside of linux/include (C files)
2012-03-24Merge tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into next/driversArnd Bergmann5-6/+94
The pxa regulator branch removes the bq24022 driver, while a lot of other regulator drivers got added in the regulator tree. This resolves the trivial conflicts by merging in the regulator patches that are already merged into v3.4. Conflicts: drivers/regulator/Kconfig drivers/regulator/Makefile Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2012-03-18Merge remote-tracking branch 'regulator/topic/supply' into regulator-nextMark Brown1-2/+0
2012-03-18Merge remote-tracking branches 'regulator/topic/devm' and 'regulator/topic/stub' into regulator-nextMark Brown1-0/+22
2012-03-18Merge remote-tracking branch 'regulator/topic/stub' into regulator-nextMark Brown1-0/+13
2012-03-18Merge remote-tracking branch 'regulator/topic/drivers' into regulator-nextMark Brown1-0/+57
2012-03-16device.h: audit and cleanup users in main include dirPaul Gortmaker1-1/+2
The <linux/device.h> header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-03-07regulator: Remove bq24022 regulator driverHeiko Stübner1-24/+0
The bq24022 driver is just a specialised form of a gpio-regulator. As all former users of it now use the gpio-regulator directly, there is no need to keep it around. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
2012-03-06mfd: Support AB9540 ab8500 variantLinus Walleij1-1/+69
The AB9540 variant of the AB8500 is basically close enough to use the same driver. This adds the new registers and deviations for this new chip variant. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@stericsson.com> Signed-off-by: Alex Macro <alex.macro@stericsson.com> Signed-off-by: Michel Jaouen <michel.jaouen@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.