summaryrefslogtreecommitdiff
path: root/include/linux/regmap.h
AgeCommit message (Collapse)AuthorFilesLines
2017-02-03Merge remote-tracking branches 'regmap/topic/doc' and 'regmap/topic/rbtree' ↵Mark Brown1-48/+67
into regmap-next
2017-01-12regmap: Fixup the kernel-doc comments on functions/structuresCharles Keepax1-48/+67
Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-10-29Merge remote-tracking branches 'regmap/fix/header' and 'regmap/fix/macro' ↵Mark Brown1-5/+6
into regmap-linus
2016-10-28regmap: Rename ret variable in regmap_read_poll_timeoutCharles Keepax1-5/+5
As almost all of the callers of the regmap_read_poll_timeout macro will include a local ret variable we will always get a Sparse warning about the duplication of the ret variable: warning: symbol 'ret' shadows an earlier one Simply rename the ret variable in the marco to pollret to make this significantly less likely to happen. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-10-13regmap: include <linux/delay.h> from include/linux/regmap.hMasahiro Yamada1-0/+1
The readx_poll_timeout() macro calls usleep_range(), which is declared in <linux/delay.h>. Make include/linux/regmap.h include <linux/delay.h>, like include/linux/iopoll.h does. Otherwise, users of the macro will see "implicit declaration of function 'usleep_range'" error. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-16regmap: Allow longer flag masks for read and writeTony Lindgren1-4/+4
We currently only support masking the top bit for read and write flags. Let's make the mask unsigned long and mask the bytes based on the configured register length to make things more generic. This allows using regmap for more exotic combinations like SPI devices that need little endian addressing. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-15Merge remote-tracking branches 'regmap/topic/bulk', 'regmap/topic/i2c', ↵Mark Brown1-0/+49
'regmap/topic/iopoll', 'regmap/topic/irq' and 'regmap/topic/maintainers' into regmap-next
2016-07-15regmap: add iopoll-like polling macroPhilipp Zabel1-0/+39
This patch adds a macro regmap_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_read. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-03regmap: irq: Add support to call client specific pre/post interrupt serviceLaxman Dewangan1-0/+10
Regmap irq implements the generic interrupt service routine which is common for most of devices. Some devices, like MAX77620, MAX20024 needs the special handling before and after servicing the interrupt as generic. For the example, MAX77620 programming guidelines for interrupt servicing says: 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting GLBLM. 2. Read IRQTOP and service the interrupt accordingly. 3. Once all interrupts has been checked and serviced, the interrupt service routine un-masks the hardware interrupt line by clearing GLBLM. The step (2) is implemented in regmap irq as generic routine. For step (1) and (3), add callbacks from regmap irq to client driver to handle chip specific configurations. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-05Merge remote-tracking branch 'regmap/topic/update-bits' into regmap-nextMark Brown1-48/+49
2016-03-05Merge remote-tracking branches 'regmap/topic/devm-irq', 'regmap/topic/doc', ↵Mark Brown1-1/+9
'regmap/topic/irq' and 'regmap/topic/stride' into regmap-next
2016-03-05regmap: irq: add devm apis for regmap_{add,del}_irq_chipLaxman Dewangan1-0/+8
Add device managed APIs for regmap_add_irq_chip() and regmap_del_irq_chip() so that it can be managed by device framework for freeing it. This helps on following: 1. Maintaining the sequence of resource allocation and deallocation regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq) On free path: regmap_del_irq_chip(d); and then removing the irq registration. On this case, regmap irq is deleted before the irq is free. This force to use normal irq registration. By using devm apis, the sequence can be maintain properly: devm_regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq); and resource deallocation will be done in reverse order by device framework. 2. No need to delete the regmap_irq_chip in error path or remove callback and hence there is less code on this path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-05regmap: replace regmap_write_bits()Kuninori Morimoto1-9/+3
commit 23b92e4cf5fd ("regmap: remove regmap_write_bits()") removed regmap_write_bits(), but MFD driver was using it. So, commit e30fccd6771d ("regmap: Keep regmap_write_bits()") turns out it, but it is using original style. This patch uses regmap_update_bits_base() for regmap_write_bits() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-26regmap: add regmap_fields_force_xxx() macrosKuninori Morimoto1-2/+4
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-26regmap: add regmap_field_force_xxx() macrosKuninori Morimoto1-0/+4
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_fields_update_bits() into macroKuninori Morimoto1-2/+2
This patch merges regmap_fields_update_bits() into macro by using regmap_field_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_fields_write() into macroKuninori Morimoto1-2/+3
This patch merges regmap_fields_write() into macro by using regmap_fields_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: add regmap_fields_update_bits_base()Kuninori Morimoto1-0/+12
This patch adds new regmap_fields_update_bits_base() which is using regmap_update_bits_base(). Current regmap_fields_xxx() can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_field_update_bits() into macroKuninori Morimoto1-2/+2
This patch merges regmap_field_update_bits() into macro by using regmap_field_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_field_write() into macroKuninori Morimoto1-1/+3
This patch merges regmap_field_write() into macro by using regmap_field_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: add regmap_field_update_bits_base()Kuninori Morimoto1-1/+11
This patch adds new regmap_field_update_bits_base() which is using regmap_update_bits_base(). Current regmap_field_xxx() can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_update_bits_check_async() into macroKuninori Morimoto1-13/+2
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch merges regmap_update_bits_check_async() into macro by using regmap_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_update_bits_check() into macroKuninori Morimoto1-12/+2
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch merges regmap_update_bits_check() into macro by using regmap_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_update_bits_async() into macroKuninori Morimoto1-10/+2
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch merges regmap_update_bits_async() into macro by using regmap_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: merge regmap_update_bits() into macroKuninori Morimoto1-9/+3
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch merges regmap_update_bits() into macro by using regmap_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: add regmap_update_bits_base()Kuninori Morimoto1-0/+11
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch adds new regmap_update_bits_base() which is feature merged function. Above functions can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15regmap: irq: add devm apis for regmap_{add,del}_irq_chipLaxman Dewangan1-0/+8
Add device managed APIs for regmap_add_irq_chip() and regmap_del_irq_chip() so that it can be managed by device framework for freeing it. This helps on following: 1. Maintaining the sequence of resource allocation and deallocation regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq) On free path: regmap_del_irq_chip(d); and then removing the irq registration. On this case, regmap irq is deleted before the irq is free. This force to use normal irq registration. By using devm apis, the sequence can be maintain properly: devm_regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq); and resource deallocation will be done in reverse order by device framework. 2. No need to delete the regmap_irq_chip in error path or remove callback and hence there is less code on this path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-22regmap: clairify meaning of max_registerStefan Agner1-1/+1
The exact meaning of max_register is not entierly clear. Follow the common wording and use "address" instead of "index". Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-05Merge remote-tracking branches 'regmap/topic/64bit' and ↵Mark Brown1-0/+16
'regmap/topic/irq-type' into regmap-next
2016-01-05regmap: irq: add support for configuration of trigger typeLaxman Dewangan1-0/+16
Some of devices supports the trigger level for interrupt like rising/falling edge specially for GPIOs. The interrupt support of such devices may have uses the generic regmap irq framework for implementation. Add support to configure the trigger type device interrupt register via regmap-irq framework. The regmap-irq framework configures the trigger register only if the details of trigger type registers are provided. [Fixed use of terery operator for legibility -- broonie] Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-12-01regmap: Fix leftover from struct reg_default to struct reg_sequence changeDaniel Wagner1-1/+1
In 8019ff6cfc04 ("regmap: Use reg_sequence for multi_reg_write / register_patch") struct reg_default was renamed to struct reg_secquence, which missed one place to fix up. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-12Merge remote-tracking branches 'regmap/topic/atomic', 'regmap/topic/debugfs' ↵Mark Brown1-0/+3
and 'regmap/topic/irq-hdr' into regmap-next
2015-10-12Merge tag 'regmap-offload-update-bits' into regmap-nextMark Brown1-0/+3
regmap: Allow buses to provide a custom update_bits() operation Some buses provide a native _update_bits() operation which for uncached registers is faster than doing a read/modify/write cycle as it is a single bus transaction. Add support for implementing this to regmap. # gpg: Signature made Tue 06 Oct 2015 16:21:47 BST using RSA key ID 5D5487D0 # gpg: Oops: keyid_from_fingerprint: no pubkey # gpg: Oops: keyid_from_fingerprint: no pubkey # gpg: key 00000000 occurs more than once in the trustdb # gpg: key 16005C11: no public key for trusted key - skipped # gpg: key 16005C11 marked as ultimately trusted # gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" # gpg: aka "Mark Brown <broonie@debian.org>" # gpg: aka "Mark Brown <broonie@kernel.org>" # gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>" # gpg: aka "Mark Brown <broonie@linaro.org>" # gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
2015-10-06regmap: Allow installing custom reg_update_bits functionJon Ringle1-0/+3
This commit allows installing a custom reg_update_bits function for cases where the hardware provides a mechanism to set or clear register bits without a read/modify/write cycle. Such is the case with the Microchip ENCX24J600. If a custom reg_update_bits function is provided, it will only be used against volatile registers. Signed-off-by: Jon Ringle <jringle@gridpoint.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-24regmap: Add generic macro to define regmap_irqQipeng Zha1-0/+3
Add REGMAP_IRQ_REG macro in regmap.h to define regmap_irq structure easily for other driver module. Signed-off-by: Qipeng Zha <qipeng.zha@intel.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-09-17regmap: irq: add ack_invert flag for chips using cleared bits as ackGuo Zeng1-0/+2
An user will be CSR SiRFSoC ARM chips. Signed-off-by: Guo Zeng <Guo.Zeng@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-17regmap: irq: add support for chips who have separate unmask registersGuo Zeng1-0/+3
Some chips have separate unmask registers from mask registers for some consideration of concurrency SMP write performance. And this patch adds a flag for it. An user will be CSR SiRFSoC ARM chips. Signed-off-by: Guo Zeng <Guo.Zeng@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-04Merge remote-tracking branches 'regmap/topic/lockdep' and ↵Mark Brown1-52/+311
'regmap/topic/seq-delay' into regmap-next
2015-09-04Merge remote-tracking branches 'regmap/topic/debugfs' and ↵Mark Brown1-0/+11
'regmap/topic/force-update' into regmap-next
2015-08-30regmap: regmap max_raw_read/write getter functionsMarkus Pargmann1-0/+2
Add functions to access the maximum size we can read/write using regmap_raw_read/write(). This helps drivers that need to know how much they can write with the raw functions without problems. There are some devices (e.g. bmc150) that have fifos as registers which need to be read in specific chunks otherwise samples are dropped. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-30regmap: Introduce max_raw_read/write for regmap_bulk_read/writeMarkus Pargmann1-0/+4
There are some buses which have a limit on the maximum number of bytes that can be send/received. An example for this is I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of more than 32 bytes. The regmap_bulk operations should still be able to utilize the full 32 bytes in this case. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-21regmap: Add missing comments about struct regmap_busMarkus Pargmann1-1/+4
There are some fields of this struct undocumented or old. This patch updates the missing comments. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11regmap: Move documentation to regmap.hNicolas Boichat1-11/+162
Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-07regmap: Use different lockdep class for each regmap init callNicolas Boichat1-49/+143
Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-17regmap: Apply optional delay in multi_reg_write/register_patchNariman Poushin1-1/+4
Add an optional delay_us field in reg_sequence to allow the client to specify a delay (in microseconds) to be applied after any given write in a sequence of writes. We treat a delay in a sequence the same way we treat a page change as they are logically similar in that you can coalesce all write before a delay (in the same way you can coalesce all writes before a page change is needed) Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-17regmap: Use reg_sequence for multi_reg_write / register_patchNariman Poushin1-3/+14
Separate the functionality using sequences of register writes from the functions that take register defaults. This change renames the arguments in order to support the extension of reg_sequence to take an optional delay to be applied after any given register in a sequence is written. This avoids adding an int to all register defaults, which could substantially increase memory usage for regmaps with large default tables. This also updates all the clients of multi_reg_write/register_patch. Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-10regmap: add regmap_fields_force_write()Kuninori Morimoto1-0/+2
regmap_fields_force_write() is similar to regmap_fields_write(), but regmap_fields_force_write() write data to register even though it is same value. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-10regmap: add regmap_write_bits()Kuninori Morimoto1-0/+9
regmap_write_bits() is similar to regmap_update_bits(), but regmap_write_bits() write data to register even though it is same value. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-22regmap: Introduce regmap_get_reg_strideSrinivas Kandagatla1-0/+7
This patch introduces regmap_get_reg_stride() function which would be used by the infrastructures like nvmem framework built on top of regmap. Mostly this function would be used for sanity checks on inputs within such infrastructure. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-22regmap: Introduce regmap_get_max_registerSrinivas Kandagatla1-0/+7
This patch introduces regmap_get_max_register() function which would be used by the infrastructures like nvmem framework built on top of regmap. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>