summaryrefslogtreecommitdiffstats
path: root/drivers/mfd/wm8994-regmap.c
AgeCommit message (Collapse)Author
2012-03-28Merge tag 'mfd_3.4-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 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-24Merge tag 'device-for-3.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux 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-16mfd: wm8994: Fix register default for WM1811 AntiPOP2Mark Brown
Should be all bits clear. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-03-16mfd: wm8994: Remove defaults for volatile registersMark Brown
Some volatile registers accidentally had defaults added, though there were no harmful side effects other than increased memory consumption. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-03-11device.h: cleanup users outside of linux/include (C files)Paul Gortmaker
For files that are actively using linux/device.h, make sure that they call it out. This will allow us to clean up some of the implicit uses of linux/device.h within include/* without introducing build regressions. Yes, this was created by "cheating" -- i.e. the headers were cleaned up, and then the fallout was found and fixed, and then the two commits were reordered. This ensures we don't introduce build regressions into the git history. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-03-06mfd: Correct readability of WM8994 DC servo 4E registerMark Brown
It should be marked as readable but wasn't, breaking DC servo operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-03-06mfd: wm8994: Mark MICBIAS register as readableMark Brown
Omitted in the regmap conversion. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-03-01mfd: Correct readability of WM8994 DC servo 4E registerMark Brown
It should be marked as readable but wasn't, breaking DC servo operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2011-12-13mfd: Mark WM1811 GPIO6 register volatile for later revisionsMark Brown
For later chip revisions the WM1811 GPIO6 register is always volatile so store the device revision when initialising the driver and then check at runtime if we're running on a newer device. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com>
2011-12-13mfd: Initialise WM8994 register cache after reading chip ID registersMark Brown
The different devices handled by the WM8994 can be distinguished using their ID registers so we don't need to rely on the user having registered the device correctly. Instead do the initial regmap setup with a minimal configuration only supporting physical I/O and then configure the cache once we have identified the device. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com>
2011-12-13mfd: Add wm8994 register access and default informationMark Brown
Describe the register map to the regmap core so that we can use its diagnostic features and cache support. This is split out from the patch using it due to the size so that the actual code change is a bit clearer. As the various devices are supersets of each other the access maps are built up by layering the functions on top of each other, though the interface for specifying the register defaults isn't currently amenable to this. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com>