summaryrefslogtreecommitdiff
path: root/drivers/mfd/wm8994-regmap.c
AgeCommit message (Collapse)AuthorFilesLines
2015-08-11mfd: wm8994-regmap: Constify reg_default tablesAxel Lin1-3/+3
These reg_default tables are not modified after initialized, so make them const. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-26mfd: wm8994: Export symbols ready for built-in => modular buildLee Jones1-0/+4
We'd like to be able to build the WM8994 family as modules, but the build will fail if the external symbols aren't exported first. Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: wm8994: Add a bunch of missing defaults/readablesCharles Keepax1-0/+64
Ever since this commit: commit d4807ad2c4c0e17b6f00e3be9492c81de0804f40 regmap: Check readable regs in _regmap_read Regmap will refuse to read a register which is not marked as readable, this has highlighted a number of controls in this driver which are not marked as readable/missing defaults. This patch corrects the situation, by adding the missing readables/defaults. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2012-09-14mfd: wm8994: Implement support for WM1811 devices with higher cust_idsMark Brown1-1/+1
Higher cust_ids have had the device revision field reset so need different handling of GPIO6. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-05-01mfd: Cache wm8994 chip revisionMark Brown1-1/+0
There's no need to mark the chip revision registers as volatile, it won't change at runtime so we can cache it from the device at startup. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-03-29Merge tag 'mfd_3.4-1' of ↵Linus Torvalds1-18/+2
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 Torvalds1-0/+1
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 Brown1-1/+1
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 Brown1-17/+0
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 Gortmaker1-0/+1
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 Brown1-0/+1
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 Brown1-0/+1
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 Brown1-0/+1
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-12mfd: Mark WM1811 GPIO6 register volatile for later revisionsMark Brown1-2/+17
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-12mfd: Initialise WM8994 register cache after reading chip ID registersMark Brown1-0/+5
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-12mfd: Add wm8994 register access and default informationMark Brown1-0/+1218
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>