aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/base/regmap (follow)
AgeCommit message (Collapse)AuthorFilesLines
2013-07-26driver core: replace strict_strto*() with kstrto*()Jingoo Han1-1/+1
The usage of strict_strto*() is not preferred, because strict_strto*() is obsolete. Thus, kstrto*() should be used. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-15Merge tag 'regmap-v3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmapLinus Torvalds1-1/+1
Pull regmap fix from Mark Brown: "Fix regmap crash for async operation on busless maps This fixes a crash if something tries to do an asynchronous operation on busless maps which was introduced during the merge window" * tag 'regmap-v3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: cache: bail in regmap_async_complete() for bus-less maps
2013-07-04regmap: cache: bail in regmap_async_complete() for bus-less mapsDaniel Mack1-1/+1
Commit f8bd822cb ("regmap: cache: Factor out block sync") made regcache_rbtree_sync() call regmap_async_complete(), which in turn does not check for map->bus before dereferencing it. This causes a NULL pointer dereference on bus-less maps. Signed-off-by: Daniel Mack <zonque@gmail.com> Cc: stable@vger.kernel.org [v3.10 only] Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-30Merge remote-tracking branch 'regmap/topic/field' into regmap-nextMark Brown2-0/+138
2013-06-30Merge remote-tracking branch 'regmap/topic/debugfs' into regmap-nextMark Brown1-2/+2
2013-06-30Merge remote-tracking branch 'regmap/topic/core' into regmap-nextMark Brown1-1/+4
2013-06-30Merge remote-tracking branch 'regmap/topic/cache' into regmap-nextMark Brown5-27/+145
2013-06-19regmap: debugfs: Suppress cache for partial register filesMark Brown1-0/+4
The cache is based on the full register map so confuses things if used for a partial map. Reported-by: Bard Liao <bardliao@realtek.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-06-12regmap: Add regmap_field APIsSrinivas Kandagatla2-0/+138
It is common to access regmap registers at bit level, using regmap_update_bits or regmap_read functions, however the end user has to take care of a mask or shifting. This becomes overhead when such use cases are high. Having a common function to do this is much convenient and less error prone. The idea of regmap_field is simple, regmap_field gives a logical structure to bits of the regmap register, and the driver can use this logical entity without the knowledge of the bit positions and masks all over the code. This way code looks much neat and it need not handle the masks, shifts every time it access the those entities. With this new regmap_field_read/write apis the end user can setup a regmap field using regmap_field_init and use the return regmap_field to read write the register field without worrying about the masks or shifts. Also this apis will be useful for drivers which are based on regmaps, like some clocks or pinctrls which can work on the regmap_fields directly without having to worry about bit positions. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-03Merge remote-tracking branch 'regmap/fix/debugfs' into regmap-linusMark Brown1-1/+4
2013-06-03regmap: core: Cache all registers by default when cache is enabledMark Brown1-1/+4
Currently all register maps with a cache need to provide a volatile callback since the default is to assume all registers are volatile. This is not sensible if we have a cache so change the default to be fully cached if a cache is provided. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-03regmap: Implemented default cache sync operationMaarten ter Huurne1-4/+42
This can be used for cache types for which syncing values one by one is equally efficient as syncing a range, such as the flat cache. Signed-off-by: Maarten ter Huurne <maarten@treewalker.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-01regmap: rbtree: Fixed node range check on syncMaarten ter Huurne1-2/+0
A node starting before the minimum register is no reason to reject it, since its end could be in range. The check for the end already exists two lines lower, so we can just remove the incorrect check. Signed-off-by: Maarten ter Huurne <maarten@treewalker.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-05-25regmap: Make regmap-mmio usable from atomic contextsLars-Peter Clausen2-2/+6
regmap-mmio uses a spinlock with spin_lock() and spin_unlock() for locking. To be able to use the regmap API from different contexts (atomic vs non-atomic), without the risk of race conditions, we need to use spin_lock_irqsave() and spin_lock_irqrestore() instead. A new field, the spinlock_flags field, is added to regmap struct to store the flags between regmap_{,un}lock_spinlock(). The spinlock_flags field itself is also protected by the spinlock. Thanks to Stephen Warren for the suggestion of this particular solution. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-23regmap: regcache: Fixup locking for custom lock callbacksLars-Peter Clausen2-12/+12
The parameter passed to the regmap lock/unlock callbacks needs to be map->lock_arg, regcache passes just map. This works fine in the case that no custom locking callbacks are used since in this case map->lock_arg equals map, but will break when custom locking callbacks are used. The issue was introduced in commit 0d4529c5("regmap: make lock/unlock functions customizable") and is fixed by this patch. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-23regmap: regcache: Fixup locking for custom lock callbacksLars-Peter Clausen2-14/+14
The parameter passed to the regmap lock/unlock callbacks needs to be map->lock_arg, regcache passes just map. This works fine in the case that no custom locking callbacks are used, since in this case map->lock_arg equals map, but will break when custom locking callbacks are used. The issue was introduced in commit 0d4529c5 ("regmap: make lock/unlock functions customizable") and is fixed by this patch. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-14regmap: debugfs: Fix return from regmap_debugfs_get_dump_startSrinivas Kandagatla1-1/+1
regmap_debugfs_get_dump_start should return the offset of the register it should start reading from, However in the current code at one point the code does not return correct register offset. With this patch all the returns from this function takes reg_stride in to consideration to return correct offset. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-12regmap: debugfs: Don't mark lockdep as broken due to debugfs writeMark Brown1-1/+1
A register write to hardware is reasonably unlikely to cause locking dependency issues, the reason we're tainting is that unexpected changes in the hardware configuration may confuse drivers. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-12regmap: debugfs: Check return value of regmap_write()Dimitris Papastamos1-1/+4
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-12regmap: rbtree: Use range information to allocate nodesMark Brown1-2/+23
If range information has been provided then when we allocate a rbnode within a range allocate the entire range. The goal is to minimise the number of reallocations done when combining or extending blocks. At present only readability and yes_ranges are taken into account, this is expected to cover most cases efficiently. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-12regmap: rbtree: Factor out node allocationMark Brown1-14/+27
In preparation for being slightly smarter about how we allocate memory factor out the node allocation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-12regmap: Make regmap_check_range_table() a public APIMark Brown1-7/+7
Allow drivers to use an access table as part of their implementation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-12regmap: Add support for discarding parts of the register cacheMark Brown2-0/+38
Allow drivers to discard parts of the register cache, for example if part of the hardware has been reset. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-16Merge remote-tracking branch 'regmap/topic/range' into regmap-nextMark Brown2-7/+88
2013-04-16Merge remote-tracking branch 'regmap/topic/irq' into regmap-nextMark Brown1-1/+2
2013-04-16Merge remote-tracking branch 'regmap/topic/cache' into regmap-nextMark Brown5-110/+315
2013-04-16Merge remote-tracking branch 'regmap/topic/async' into regmap-nextMark Brown1-0/+8
2013-04-16regmap: don't corrupt work buffer in _regmap_raw_write()Stephen Warren1-2/+1
_regmap_raw_write() contains code to call regcache_write() to write values to the cache. That code calls memcpy() to copy the value data to the start of the work_buf. However, at least when _regmap_raw_write() is called from _regmap_bus_raw_write(), the value data is in the work_buf, and this memcpy() operation may over-write part of that value data, depending on the value of reg_bytes + pad_bytes. At least when using reg_bytes==1 and pad_bytes==0, corruption of the value data does occur. To solve this, remove the memcpy() operation, and modify the subsequent .parse_val() call to parse the original value buffer directly. At least in the case of 8-bit register address and 16-bit values, and writes of single registers at a time, this memcpy-then-parse combination used to cancel each-other out; for a work-buffer containing xx 89 03, the memcpy changed it to 89 03 03, and the parse_val changed it back to 89 89 03, thus leaving the value uncorrupted. This appears completely accidental though. Since commit 8a819ff "regmap: core: Split out in place value parsing", .parse_val only returns the parsed value, and does not modify the buffer, and hence does not (accidentally) undo the corruption caused by memcpy(). This caused bogus values to get written to HW, thus preventing e.g. audio playback on systems with a WM8903 CODEC. This patch fixes that. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-16Merge tag 'v3.9-rc7' into regmap-cacheMark Brown3-3/+6
Linux 3.9-rc7
2013-04-09regmap: Back out work buffer fixMark Brown1-1/+2
This reverts commit bc8ce4 (regmap: don't corrupt work buffer in _regmap_raw_write()) since it turns out that it can cause issues when taken in isolation from the other changes in -next that lead to its discovery. On the basis that nobody noticed the problems for quite some time without that subsequent work let's drop it from v3.9. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-05regmap: cache: Fix format specifier in dev_dbgStratos Karafotis1-1/+1
Fix format specifier in dev_dbg and suppress the following warning drivers/base/regmap/regcache.c: In function ‘regcache_sync_block_raw_flush’: drivers/base/regmap/regcache.c:593:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-05regmap: cache: Make regcache_sync_block_raw staticSachin Kamat1-1/+1
regcache_sync_block_raw is used only in this file. Hence make it static. Silences the following warning: drivers/base/regmap/regcache.c:608:5: warning: symbol 'regcache_sync_block_raw' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-31Merge remote-tracking branch 'regmap/fix/async' into tmpMark Brown1-0/+2
2013-03-31Merge remote-tracking branch 'regmap/fix/core' into tmpMark Brown1-2/+2
2013-03-30regmap: cache: Write consecutive registers in a single block writeMark Brown1-17/+47
When syncing blocks of data using raw writes combine the writes into a single block write, saving us bus overhead for setup, addressing and teardown. Currently the block write is done unconditionally as it is expected that hardware which has a register format which can support raw writes will support auto incrementing writes, this decision may need to be revised in future. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
2013-03-30regmap: cache: Split raw and non-raw syncsMark Brown1-11/+53
For code clarity after implementing block writes split out the raw and non-raw I/O sync implementations. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
2013-03-30regmap: cache: Factor out block syncMark Brown3-42/+51
The idea of holding blocks of registers in device format is shared between at least rbtree and lzo cache formats so split out the loop that does the sync from the rbtree code so optimisations on it can be reused. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
2013-03-30regmap: cache: Factor out reg_present support from rbtree cacheMark Brown3-58/+54
The idea of maintaining a bitmap of present registers is something that can usefully be used by other cache types that maintain blocks of cached registers so move the code out of the rbtree cache and into the generic regcache code. Refactor the interface slightly as we go to wrap the set bit and enlarge bitmap operations (since we never do one without the other) and make it more robust for reads of uncached registers by bounds checking before we look at the bitmap. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
2013-03-27regmap: async: Add missing returnMark Brown1-0/+2
Let's only write once... Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-27regmap: cache: Use raw I/O to sync rbtrees if we canMark Brown1-1/+18
This will bring no meaningful benefit by itself, it is done as a separate commit to aid bisection if there are problems with the following commits adding support for coalescing adjacent writes. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-27regmap: core: Provide regmap_can_raw_write() operationMark Brown1-3/+12
Mainly useful internally but exported since this is a public API that's being checked for. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-26regmap: cache: Provide a get address of value operationMark Brown2-2/+9
Provide a helper to do the size based index into a block of registers and use it when reading a value. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-26regmap: Cut down on the average # of nodes in the rbtree cacheDimitris Papastamos1-1/+69
This patch aims to bring down the average number of nodes in the rbtree cache and increase the average number of registers per node. This should improve general lookup and traversal times. This is achieved by setting the minimum size of a block within the rbnode to the size of the rbnode itself. This will essentially cache possibly non-existent registers so to combat this scenario, we keep a separate bitmap in memory which keeps track of which register exists. The memory overhead of this change is likely in the order of ~5-10%, possibly less depending on the register file layout. On my test system with a bitmap of ~4300 bits and a relatively sparse register layout, the memory requirements for the entire cache did not increase (the cutting down of nodes which was about 50% of the original number compensated the situation). A second patch that can be built on top of this can look at the ratio `sizeof(*rbnode) / map->cache_word_size' in order to suitably adjust the block length of each block. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-26regmap: core: Make raw write available to regcacheMark Brown2-2/+5
This allows the cache to sync values directly to the device when stored in native format and also allows asynchronous I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-26regmap: core: Warn on invalid operation combinationsMark Brown1-5/+5
Don't grind to a screaming halt, just generate a warning. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-21regmap: don't corrupt work buffer in _regmap_raw_write()Stephen Warren1-2/+1
_regmap_raw_write() contains code to call regcache_write() to write values to the cache. That code calls memcpy() to copy the value data to the start of the work_buf. However, at least when _regmap_raw_write() is called from _regmap_bus_raw_write(), the value data is in the work_buf, and this memcpy() operation may over-write part of that value data, depending on the value of reg_bytes + pad_bytes. At least when using reg_bytes==1 and pad_bytes==0, corruption of the value data does occur. To solve this, remove the memcpy() operation, and modify the subsequent .parse_val() call to parse the original value buffer directly. At least in the case of 8-bit register address and 16-bit values, and writes of single registers at a time, this memcpy-then-parse combination used to cancel each-other out; for a work-buffer containing xx 89 03, the memcpy changed it to 89 03 03, and the parse_val changed it back to 89 89 03, thus leaving the value uncorrupted. This appears completely accidental though. Since commit 8a819ff "regmap: core: Split out in place value parsing", .parse_val only returns the parsed value, and does not modify the buffer, and hence does not (accidentally) undo the corruption caused by memcpy(). This caused bogus values to get written to HW, thus preventing e.g. audio playback on systems with a WM8903 CODEC. This patch fixes that. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-19regmap: irq: Clarify error message when we fail to request primary IRQMark Brown1-1/+2
Display the name for the chip rather than just the primary IRQ so it is clearer what exactly has failed. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-13regmap: cache Fix regcache-rbtree syncLars-Peter Clausen1-1/+1
The last register block, which falls into the specified range, is not handled correctly. The formula which calculates the number of register which should be synced is inverse (and off by one). E.g. if all registers in that block should be synced only one is synced, and if only one should be synced all (but one) are synced. To calculate the number of registers that need to be synced we need to subtract the number of the first register in the block from the max register number and add one. This patch updates the code accordingly. The issue was introduced in commit ac8d91c ("regmap: Supply ranges to the sync operations"). Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org
2013-03-13regmap: rbtree Expose total memory consumption in the rbtree debugfs entryDimitris Papastamos1-2/+7
Provide a feel of how much overhead the rbtree cache adds to the game. [Slightly reworded output in debugfs -- broonie] Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-12regmap: Initialize `map->debugfs' before regcacheDimitris Papastamos1-2/+2
In the rbtree code we are exposing statistics relating to the number of nodes/registers of the rbtree cache for each of the devices. Ensure that `map->debugfs' has been initialized before we attempt to initialize the debugfs entry for the rbtree cache. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org