kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/base/regmap/internal.h

354 lines
10 KiB
Raw Normal View History

regmap: add proper SPDX identifiers on files that did not have them. There were a few files in the regmap code that did not have SPDX identifiers on them, so fix that up. At the same time, remove the "free form" text that specified the license of the file, as that is impossible for any tool to properly parse. Also, as Mark loves // comment markers, convert all of the headers to be the same to make things look consistent :) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-25 20:06:18 +02:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Fix implicit inclusion of device.h internal.h is using dev_name() but doesn't include device.h which defines it. Add an explicit include to avoid build problems due to this. Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-29 12:28:33 -07:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: debugfs: Cache offsets of valid regions for dump Avoid doing a linear scan of the entire register map for each read() of the debugfs register dump by recording the offsets where valid registers exist when we first read the registers file. This assumes the set of valid registers never changes, if this is not the case invalidation of the cache will be required. This could be further improved for large blocks of contiguous registers by calculating the register we will read from within the block - currently we do a linear scan of the block. An rbtree may also be worthwhile. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-11 01:24:29 +09:00
regmap: Add asynchronous I/O support Some use cases like firmware download can transfer a lot of data in quick succession. With high speed buses these use cases can benefit from having multiple transfers scheduled at once since this allows the bus to minimise the delay between transfers. Support this by adding regmap_raw_write_async(), allowing raw transfers to be scheduled, and regmap_async_complete() to wait for them to finish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 22:07:38 +08:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: debugfs: Cache offsets of valid regions for dump Avoid doing a linear scan of the entire register map for each read() of the debugfs register dump by recording the offsets where valid registers exist when we first read the registers file. This assumes the set of valid registers never changes, if this is not the case invalidation of the cache will be required. This could be further improved for large blocks of contiguous registers by calculating the register we will read from within the block - currently we do a linear scan of the block. An rbtree may also be worthwhile. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-11 01:24:29 +09:00
regmap: debugfs: Add a `max_reg' member in struct regmap_debugfs_off_cache We are keeping track of the maximum register as well, this will make things easier for us in sharing this code with the code implementing the register ranges functionality. It also simplifies a bit the calculations when looking for the relevant block:offset from within the cache. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-08 12:47:14 +00:00
regmap: debugfs: Cache offsets of valid regions for dump Avoid doing a linear scan of the entire register map for each read() of the debugfs register dump by recording the offsets where valid registers exist when we first read the registers file. This assumes the set of valid registers never changes, if this is not the case invalidation of the cache will be required. This could be further improved for large blocks of contiguous registers by calculating the register we will read from within the block - currently we do a linear scan of the block. An rbtree may also be worthwhile. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-11 01:24:29 +09:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Add support for padding between register and address Some devices, especially those with high speed control interfaces, require padding between the register and the data. Support this in the regmap API by providing a pad_bits configuration parameter. Only devices with integer byte counts are supported. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-18 10:52:25 +00:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: allow upshifting register addresses before performing operations Similar to the existing reg_downshift mechanism, that is used to translate register addresses on busses that have a smaller address stride, it's also possible to want to upshift register addresses. Such a case was encountered when network PHYs and PCS that usually sit on a MDIO bus (16-bits register with a stride of 1) are integrated directly as memory-mapped devices. Here, the same register layout defined in 802.3 is used, but the register now have a larger stride. Introduce a mechanism to also allow upshifting register addresses. Re-purpose reg_downshift into a more generic, signed reg_shift, whose sign indicates the direction of the shift. To avoid confusion, also introduce macros to explicitly indicate if we want to downshift or upshift. For bisectability, change any use of reg_downshift to use reg_shift. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20230407152604.105467-1-maxime.chevallier@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-04-07 17:26:04 +02:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Use pad_bits and reg_bits when determining register format. This change combines any padding bits into the register address bits when determining register format handlers to use the next byte-divisible register size. A reg_shift member is introduced to the regmap struct to enable fixup of the reg format. Format handlers now take an extra parameter specifying the number of bits to shift the value by. Signed-off-by: Marc Reilly <marc@cpdesign.com.au> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-16 12:11:43 +11:00
regmap: core: Split out in place value parsing Currently the value parsing operations both return the parsed value and modify the passed buffer. This precludes their use in places like the cache code so split out the in place modification into a new parse_inplace() operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-04 09:04:51 +08:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Add asynchronous I/O support Some use cases like firmware download can transfer a lot of data in quick succession. With high speed buses these use cases can benefit from having multiple transfers scheduled at once since this allows the bus to minimise the delay between transfers. Support this by adding regmap_raw_write_async(), allowing raw transfers to be scheduled, and regmap_async_complete() to wait for them to finish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 22:07:38 +08:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: change struct regmap's internal locks as union this patch change struct regmap->mutex and struct regmap->spinlock as an union, because these 2 members are only used one of them, we change it to shrink the struct size. Signed-off-by: Yalin Wang <yalin.wang@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-11 16:19:49 +08:00
regmap: Move spinlock_flags into the union This patch move struct regmap.spinlock_flags into the union of spinlock, so that we can shrink struct regmap size. Signed-off-by: Yalin Wang <yalin.wang@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-12-15 16:05:50 +08:00
regmap: teach regmap to use raw spinlocks if requested in the config Some drivers might access regmap in a context where a raw spinlock is held. An example is drivers/irqchip/irq-ls-extirq.c, which calls regmap_update_bits() from struct irq_chip :: irq_set_type, which is a method called by __irq_set_trigger() under the desc->lock raw spin lock. Since desc->lock is a raw spin lock and the regmap internal lock for mmio is a plain spinlock (which can become sleepable on RT), this is an invalid locking scheme and we get a splat stating that this is a "[ BUG: Invalid wait context ]". It seems reasonable for regmap to have an option use a raw spinlock too, so add that in the config such that drivers can request it. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210825205041.927788-2-vladimir.oltean@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-25 23:50:40 +03:00
regmap: change struct regmap's internal locks as union this patch change struct regmap->mutex and struct regmap->spinlock as an union, because these 2 members are only used one of them, we change it to shrink the struct size. Signed-off-by: Yalin Wang <yalin.wang@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-11 16:19:49 +08:00
regmap: maple: Provide lockdep (sub)class for maple tree's internal lock In some cases when using the maple tree register cache, the lockdep validator might complain about invalid deadlocks: [7.131886] Possible interrupt unsafe locking scenario: [7.131890] CPU0 CPU1 [7.131893] ---- ---- [7.131896] lock(&mt->ma_lock); [7.131904] local_irq_disable(); [7.131907] lock(rockchip_drm_vop2:3114:(&vop2_regmap_config)->lock); [7.131916] lock(&mt->ma_lock); [7.131925] <Interrupt> [7.131928] lock(rockchip_drm_vop2:3114:(&vop2_regmap_config)->lock); [7.131936] *** DEADLOCK *** [7.131939] no locks held by swapper/0/0. [7.131944] the shortest dependencies between 2nd lock and 1st lock: [7.131950] -> (&mt->ma_lock){+.+.}-{2:2} { [7.131966] HARDIRQ-ON-W at: [7.131973] lock_acquire+0x200/0x330 [7.131986] _raw_spin_lock+0x50/0x70 [7.131998] regcache_maple_write+0x68/0xe0 [7.132010] regcache_write+0x6c/0x90 [7.132019] _regmap_read+0x19c/0x1d0 [7.132029] _regmap_update_bits+0xc0/0x148 [7.132038] regmap_update_bits_base+0x6c/0xa8 [7.132048] rk8xx_probe+0x22c/0x3d8 [7.132057] rk8xx_spi_probe+0x74/0x88 [7.132065] spi_probe+0xa8/0xe0 [...] [7.132675] } [7.132678] ... key at: [<ffff800082943c20>] __key.0+0x0/0x10 [7.132691] ... acquired at: [7.132695] _raw_spin_lock+0x50/0x70 [7.132704] regcache_maple_write+0x68/0xe0 [7.132714] regcache_write+0x6c/0x90 [7.132724] _regmap_read+0x19c/0x1d0 [7.132732] _regmap_update_bits+0xc0/0x148 [7.132741] regmap_field_update_bits_base+0x74/0xb8 [7.132751] vop2_plane_atomic_update+0x480/0x14d8 [rockchipdrm] [7.132820] drm_atomic_helper_commit_planes+0x1a0/0x320 [drm_kms_helper] [...] [7.135112] -> (rockchip_drm_vop2:3114:(&vop2_regmap_config)->lock){-...}-{2:2} { [7.135130] IN-HARDIRQ-W at: [7.135136] lock_acquire+0x200/0x330 [7.135147] _raw_spin_lock_irqsave+0x6c/0x98 [7.135157] regmap_lock_spinlock+0x20/0x40 [7.135166] regmap_read+0x44/0x90 [7.135175] vop2_isr+0x90/0x290 [rockchipdrm] [7.135225] __handle_irq_event_percpu+0x124/0x2d0 In the example above, the validator seems to get the scope of dependencies wrong, since the regmap instance used in rk8xx-spi driver has nothing to do with the instance from vop2. Improve validation by sharing the regmap's lockdep class with the maple tree's internal lock, while also providing a subclass for the latter. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20241031-regmap-maple-lockdep-fix-v2-1-06a3710f3623@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-10-31 18:37:04 +02:00
regmap: introduce fast_io busses, and use a spinlock for them Some bus types have very fast IO. For these, acquiring a mutex for every IO operation is a significant overhead. Allow busses to indicate their IO is fast, and enhance regmap to use a spinlock for those busses. [Currently limited to native endian registers -- broonie] Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-04 15:48:28 -06:00
regmap: make lock/unlock functions customizable It is sometimes convenient for a regmap user to override the standard regmap lock/unlock functions with custom functions. For instance this can be useful in case an already existing spinlock or mutex has to be used for locking a set of registers instead of the internal regmap spinlock/mutex. Note that the fast_io field of struct regmap_bus is ignored in case custom locking functions are used. Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-10-16 15:56:59 +02:00
regmap: Allocate buffers with GFP_ATOMIC when fast_io == true If a regmap is using fast_io, allocate the scratch buffer in regmap_bulk_write() with GFP_ATOMIC instead of GFP_KERNEL. Otherwise we may schedule while atomic. Reported-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-11 16:37:05 -07:00
regmap: allow a defined reg_base to be added to every address There's an inconsistency that arises when a register set can be accessed internally via MMIO, or externally via SPI. The VSC7514 chip allows both modes of operation. When internally accessed, the system utilizes __iomem, devm_ioremap_resource, and devm_regmap_init_mmio. For SPI it isn't possible to utilize memory-mapped IO. To properly operate, the resource base must be added to the register before every operation. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20220313224524.399947-3-colin.foster@in-advantage.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-03-13 15:45:24 -07:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: introduce explicit bus_context for bus callbacks The only context needed by I2C and SPI bus definitions is the device itself; this can be converted to an i2c_client or spi_device in order to perform IO on the device. However, other bus types may need more context in order to perform IO. Enable this by having regmap_init accept a bus_context parameter, and pass this to all bus callbacks. The existing callbacks simply pass the struct device here. Future bus types may pass something else. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-04 15:48:30 -06:00
regmap: Implement dev_get_regmap() Use devres to implement dev_get_regmap(). This should mean that in almost all cases devices wishing to take advantage of framework features based on regmap shouldn't need to explicitly pass the regmap into the framework. This simplifies device setup a bit. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-08 17:44:40 +01:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Add asynchronous I/O support Some use cases like firmware download can transfer a lot of data in quick succession. With high speed buses these use cases can benefit from having multiple transfers scheduled at once since this allows the bus to minimise the delay between transfers. Support this by adding regmap_raw_write_async(), allowing raw transfers to be scheduled, and regmap_async_complete() to wait for them to finish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 22:07:38 +08:00
regmap: Cache async work structures Rather than allocating and deallocating the structures used to manage async transfers each time we do one keep the structures around as long as the regmap is around. This should provide a small performance improvement. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-07 23:00:24 +01:00
regmap: Add asynchronous I/O support Some use cases like firmware download can transfer a lot of data in quick succession. With high speed buses these use cases can benefit from having multiple transfers scheduled at once since this allows the bus to minimise the delay between transfers. Support this by adding regmap_raw_write_async(), allowing raw transfers to be scheduled, and regmap_async_complete() to wait for them to finish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 22:07:38 +08:00
regmap: Reorder 'struct regmap' On a x86_64, with configured with allmodconfig, pahole states that the regmap structure is: /* size: 1048, cachelines: 17, members: 78 */ /* sum members: 1006, holes: 9, sum holes: 35 */ /* padding: 7 */ /* member types with holes: 2, total: 2 */ /* last cacheline: 24 bytes */ So, when such a struct is allocated, 2048 bytes are allocated, with most of this space being wasted. Move a few bools so that the size is reduced to 1024. After this change, pahole gives: /* size: 1024, cachelines: 16, members: 78 */ /* sum members: 1006, holes: 6, sum holes: 18 */ /* member types with holes: 2, total: 2 */ Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/f01f900d15633d5cda5f27763723acb307c0d22f.1737725820.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-24 14:37:58 +01:00
regmap: Add asynchronous I/O support Some use cases like firmware download can transfer a lot of data in quick succession. With high speed buses these use cases can benefit from having multiple transfers scheduled at once since this allows the bus to minimise the delay between transfers. Support this by adding regmap_raw_write_async(), allowing raw transfers to be scheduled, and regmap_async_complete() to wait for them to finish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 22:07:38 +08:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: Disable debugfs when locking is disabled The recently added support for disabling the regmap internal locking left debugfs enabled for devices with the locking disabled. This is a problem since debugfs allows userspace to do things like initiate reads from the hardware which will use the scratch buffers protected by the regmap locking so could cause data corruption. For safety address this by just disabling debugfs for these devices. That is overly conservative since some of the debugfs files just read internal data structures but it's much simpler to implmement and less likely to lead to problems with tooling that works with debugfs. Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-12-12 16:56:43 +00:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: allow regmap instances to be named Some devices have multiple separate register regions. Logically, one regmap would be created per region. One issue that prevents this is that each instance will attempt to create the same debugfs files. Avoid this by allowing regmaps to be named, and use the name to construct the debugfs directory name. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-04 15:48:29 -06:00
regmap: debugfs: fix race condition in dummy name allocation Use IDA instead of a simple counter for generating unique dummy names. The previous implementation used dummy_index++ which is not atomic, leading to potential duplicate names when multiple threads call regmap_debugfs_init() concurrently with name="dummy". Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com> Link: https://patch.msgid.link/20260409035015.950764-1-zxyan0222@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-09 11:50:15 +08:00
regmap: Cache register and value sizes for debugfs No point in calculating them every time. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-06 13:29:05 +09:00
regmap: debugfs: Cache offsets of valid regions for dump Avoid doing a linear scan of the entire register map for each read() of the debugfs register dump by recording the offsets where valid registers exist when we first read the registers file. This assumes the set of valid registers never changes, if this is not the case invalidation of the cache will be required. This could be further improved for large blocks of contiguous registers by calculating the register we will read from within the block - currently we do a linear scan of the block. An rbtree may also be worthwhile. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-11 01:24:29 +09:00
regmap: debugfs: Add a registers `range' file This file lists the register ranges in the register map. The condition to split the range is based on whether the block is readable or not. Ensure that we lock the `debugfs_off_cache' list whenever we access and modify the list. There is a possible race otherwise between the read() operations of the `registers' file and the `range' file. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-20 12:15:23 +00:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: rework ->max_register handling When regmap consists of single register, 'regmap' subsystem is unable to understand whether ->max_register is set or not, because in both cases it is equal to zero. It leads to that the logic based on value of ->max_register doesn't work. For example using of REGCACHE_FLAT fails. This patch introduces an extra parameter to regmap config, indicating that zero value in ->max_register is authentic. Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com> Link: https://lore.kernel.org/r/20240126200836.1829995-1-jan.dakinevich@salutedevices.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-26 23:08:36 +03:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Skip precious registers when dumping registers via debugfs Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-08 15:41:46 +09:00
regmap: Add regmap_noinc_write API The regmap API had a noinc_read function added for instances where devices supported returning data from an internal FIFO in a single read. This commit adds the noinc_write variant to allow writing to a non incrementing register, this is used in devices such as the sx1301 for loading firmware. Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-19 10:33:50 +01:00
regmap: Add regmap_noinc_read API The regmap API usually assumes that bulk read operations will read a range of registers but some I2C/SPI devices have certain registers for which a such a read operation will return data from an internal FIFO instead. Add an explicit API to support bulk read without range semantics. Some linux drivers use regmap_bulk_read or regmap_raw_read for such registers, for example mpu6050 or bmi150 from IIO. This only happens to work because when caching is disabled a single regmap read op will map to a single bus read op (as desired). This breaks if caching is enabled and reg+1 happens to be a cacheable register. Without regmap support refactoring a driver to enable regmap caching requires separate I2C and SPI paths. This is exactly what regmap is supposed to help avoid. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-07 17:52:17 +03:00
regmap: introduce tables for readable/writeable/volatile/precious checks Many of the regmap enabled drivers implementing one or more of the readable, writeable, volatile and precious methods use the same code pattern: return ((reg >= X && reg <= Y) || (reg >= W && reg <= Z) || ...) Switch to a data driven approach, using tables to describe readable/writeable/volatile and precious registers ranges instead. The table based check can still be overridden by passing the usual function pointers via struct regmap_config. Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-11-20 15:20:30 +01:00
regmap: Add regmap_noinc_write API The regmap API had a noinc_read function added for instances where devices supported returning data from an internal FIFO in a single read. This commit adds the noinc_write variant to allow writing to a non incrementing register, this is used in devices such as the sx1301 for loading firmware. Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-19 10:33:50 +01:00
regmap: Add regmap_noinc_read API The regmap API usually assumes that bulk read operations will read a range of registers but some I2C/SPI devices have certain registers for which a such a read operation will return data from an internal FIFO instead. Add an explicit API to support bulk read without range semantics. Some linux drivers use regmap_bulk_read or regmap_raw_read for such registers, for example mpu6050 or bmi150 from IIO. This only happens to work because when caching is disabled a single regmap read op will map to a single bus read op (as desired). This breaks if caching is enabled and reg+1 happens to be a cacheable register. Without regmap support refactoring a driver to enable regmap caching requires separate I2C and SPI paths. This is exactly what regmap is supposed to help avoid. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-07 17:52:17 +03:00
regmap: Add support for device specific write and read flag masks. Some buses like SPI have no standard notation of read or write operations. The general scheme here is to set or clear specific bits in the register address to indicate whether the operation is a read or write. We already support having a read flag mask per bus, but as there is no standard the bits which need to be set or cleared differ between devices and vendors, thus we need a mechanism to specify them per device. This patch adds two new entries to the regmap_config struct, read_flag_mask and write_flag_mask. These will be or'ed onto the top byte when doing a read or write operation. If both masks are empty the device will fallback to the regmap_bus masks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-05 20:46:32 +02:00
regmap: Add provisions to have user-defined read operation This commit is a preparatory commit to provide "no-bus" configuration option for regmap API. It adds necessary plumbing needed to have the ability to provide user define register read function. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-12 12:54:12 -08:00
regmap: Add provisions to have user-defined write operation This commit is a preparatory commit to provide "no-bus" configuration option for regmap API. It adds necessary plumbing needed to have the ability to provide user define register write function. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-12 12:54:13 -08:00
regmap: Allow installing custom reg_update_bits function 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-10-01 12:38:07 -04:00
regmap: Add bulk read/write callbacks into regmap_config Currently the regmap_config structure only allows the user to implement single element register read/write using .reg_read/.reg_write callbacks. The regmap_bus already implements bulk counterparts of both, and is being misused as a workaround for the missing bulk read/write callbacks in regmap_config by a couple of drivers. To stop this misuse, add the bulk read/write callbacks to regmap_config and call them from the regmap core code. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Mark Brown <broonie@kernel.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/r/20220430025145.640305-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-30 04:51:44 +02:00
regmap: Add provisions to have user-defined read operation This commit is a preparatory commit to provide "no-bus" configuration option for regmap API. It adds necessary plumbing needed to have the ability to provide user define register read function. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-12 12:54:12 -08:00
regmap: Add reg_default_cb callback for flat cache defaults Commit e062bdfdd6ad ("regmap: warn users about uninitialized flat cache") warns when REGCACHE_FLAT is used without full defaults. This causes false positives on hardware where many registers reset to zero but are not listed in reg_defaults, forcing drivers to maintain large tables just to silence the warning. Add a reg_default_cb() hook so drivers can supply defaults for registers not present in reg_defaults when populating REGCACHE_FLAT. This keeps the warning quiet for known zero-reset registers without bloating tables. Provide a generic regmap_default_zero_cb() helper for drivers that need zero defaults. The hook is only used for REGCACHE_FLAT; the core does not check readable/writeable access, so drivers must provide readable_reg/ writeable_reg callbacks and handle holes in the register map. Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260123095346.1258556-3-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-23 15:23:44 +05:30
regmap: Allow longer flag masks for read and write 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-09-15 13:56:10 -07:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Use pad_bits and reg_bits when determining register format. This change combines any padding bits into the register address bits when determining register format handlers to use the next byte-divisible register size. A reg_shift member is introduced to the regmap struct to enable fixup of the reg format. Format handlers now take an extra parameter specifying the number of bits to shift the value by. Signed-off-by: Marc Reilly <marc@cpdesign.com.au> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-16 12:11:43 +11:00
regmap: implement register striding regmap_config.reg_stride is introduced. All extant register addresses are a multiple of this value. Users of serial-oriented regmap busses will typically set this to 1. Users of the MMIO regmap bus will typically set this based on the value size of their registers, in bytes, so 4 for a 32-bit register. Throughout the regmap code, actual register addresses are used. Wherever the register address is used to index some array of values, the address is divided by the stride to determine the index, or vice-versa. Error- checking is added to all entry-points for register address data to ensure that register addresses actually satisfy the specified stride. The MMIO bus ensures that the specified stride is large enough for the register size. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-09 13:40:24 -06:00
regmap: core: Introduce register stride order Since the register stride should always equal to 2^N, and bit rotation is much faster than multiplication and division. So introducing the stride order and using bit rotation to get the offset of the register from the index to improve the performance. Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-04 18:00:33 +08:00
regmap: Use pad_bits and reg_bits when determining register format. This change combines any padding bits into the register address bits when determining register format handlers to use the next byte-divisible register size. A reg_shift member is introduced to the regmap struct to enable fixup of the reg format. Format handlers now take an extra parameter specifying the number of bits to shift the value by. Signed-off-by: Marc Reilly <marc@cpdesign.com.au> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-16 12:11:43 +11:00
regmap: Reorder 'struct regmap' On a x86_64, with configured with allmodconfig, pahole states that the regmap structure is: /* size: 1048, cachelines: 17, members: 78 */ /* sum members: 1006, holes: 9, sum holes: 35 */ /* padding: 7 */ /* member types with holes: 2, total: 2 */ /* last cacheline: 24 bytes */ So, when such a struct is allocated, 2048 bytes are allocated, with most of this space being wasted. Move a few bools so that the size is reduced to 1024. After this change, pahole gives: /* size: 1024, cachelines: 16, members: 78 */ /* sum members: 1006, holes: 6, sum holes: 18 */ /* member types with holes: 2, total: 2 */ Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/f01f900d15633d5cda5f27763723acb307c0d22f.1737725820.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-24 14:37:58 +01:00
regmap: Add debugfs file for forcing field writes `_regmap_update_bits()` checks if the current register value differs from the new value, and only writes to the register if they differ. When testing hardware drivers, it might be desirable to always force a register write, for example when writing to a `regmap_field`. This enables and simplifies testing and verification of the hardware interaction. For example, when using a hardware mock/simulation model, one can then more easily verify that the driver makes the correct expected register writes during certain events. Add a bool variable `force_write_field` and a corresponding debugfs entry to enable this. Since this feature could interfere with driver operation, guard it with a macro. Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://lore.kernel.org/r/pnd1qifa7sj.fsf@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13 13:42:27 +02:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
debugfs: Pass bool pointer to debugfs_create_bool() Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument, when all it needs is a boolean pointer. It would be better to update this API to make it accept 'bool *' instead, as that will make it more consistent and often more convenient. Over that bool takes just a byte. That required updates to all user sites as well, in the same commit updating the API. regmap core was also using debugfs_{read|write}_file_bool(), directly and variable types were updated for that to be bool as well. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-26 15:04:07 -07:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
debugfs: Pass bool pointer to debugfs_create_bool() Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument, when all it needs is a boolean pointer. It would be better to update this API to make it accept 'bool *' instead, as that will make it more consistent and often more convenient. Over that bool takes just a byte. That required updates to all user sites as well, in the same commit updating the API. regmap core was also using debugfs_{read|write}_file_bool(), directly and variable types were updated for that to be bool as well. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-26 15:04:07 -07:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Don't use bitfields for booleans This was a cut'n'paste from some older code. Since we're about to add debugfs support don't do the obvious thing and use bool, use u32 instead (which debugfs has been using since time immemorial). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-06 18:01:35 +00:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Use regcache_mark_dirty() to indicate power loss or reset Existing regmap users call regcache_mark_dirty() as part of the suspend/resume sequence, to tell regcache that non-default values need to be resynced post-resume. Add an internal "no_sync_defaults" regmap flag to remember this state, so that regcache_sync() can differentiate between these two cases: 1) HW was reset, so any cache values that match map->reg_defaults can be safely skipped. On some chips there are a lot of registers in the reg_defaults list, so this optimization speeds things up quite a bit. 2) HW was not reset (maybe it was just clock-gated), so if we cached any writes, they should be sent to the hardware regardless of whether they match the HW default. Currently this will write out all values in the regcache, since we don't maintain per-register dirty bits. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-05 15:14:14 -07:00
debugfs: Pass bool pointer to debugfs_create_bool() Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument, when all it needs is a boolean pointer. It would be better to update this API to make it accept 'bool *' instead, as that will make it more consistent and often more convenient. Over that bool takes just a byte. That required updates to all user sites as well, in the same commit updating the API. regmap core was also using debugfs_{read|write}_file_bool(), directly and variable types were updated for that to be bool as well. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-26 15:04:07 -07:00
regmap: Use regcache_mark_dirty() to indicate power loss or reset Existing regmap users call regcache_mark_dirty() as part of the suspend/resume sequence, to tell regcache that non-default values need to be resynced post-resume. Add an internal "no_sync_defaults" regmap flag to remember this state, so that regcache_sync() can differentiate between these two cases: 1) HW was reset, so any cache values that match map->reg_defaults can be safely skipped. On some chips there are a lot of registers in the reg_defaults list, so this optimization speeds things up quite a bit. 2) HW was not reset (maybe it was just clock-gated), so if we cached any writes, they should be sent to the hardware regardless of whether they match the HW default. Currently this will write out all values in the regcache, since we don't maintain per-register dirty bits. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-05 15:14:14 -07:00
regmap: Support register patch sets Device manufacturers frequently provide register sequences, usually not fully documented, to be run at startup in order to provide better defaults for devices (for example, improving performance in the light of silicon evaluation). Support such updates by allowing drivers to register update sets with the core. These updates will be written to the device immediately and will also be rewritten when the cache is synced. The assumption is that the reason for resyncing the cache will always be that the device has been powered off. If this turns out to not be the case then a separate operation can be provided. Currently the implementation only allows a single set of updates to be specified for a device, this could be extended in future. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-21 12:01:14 +00:00
regmap: Use reg_sequence for multi_reg_write / register_patch 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-16 16:36:21 +01:00
regcache: Define iterator inside for-loop and align their types Some of the iterators may be defined inside the respective for-loop reducing the scope and potential risk of their misuse. While at it, align their types based on the type of the upper or lower limits. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260302095847.2310066-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-02 10:56:56 +01:00
regmap: Converts group operation into single read write operations Some devices does not support bulk read and write operations, for them we have series of single write and read operations. Signed-off-by: Anthony Olech <Anthony.Olech@diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com> [Fixed coding style, don't check use_single_rw before assign --broonie ] Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-30 23:23:40 +01:00
regmap: Reorder 'struct regmap' On a x86_64, with configured with allmodconfig, pahole states that the regmap structure is: /* size: 1048, cachelines: 17, members: 78 */ /* sum members: 1006, holes: 9, sum holes: 35 */ /* padding: 7 */ /* member types with holes: 2, total: 2 */ /* last cacheline: 24 bytes */ So, when such a struct is allocated, 2048 bytes are allocated, with most of this space being wasted. Move a few bools so that the size is reduced to 1024. After this change, pahole gives: /* size: 1024, cachelines: 16, members: 78 */ /* sum members: 1006, holes: 6, sum holes: 18 */ /* member types with holes: 2, total: 2 */ Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/f01f900d15633d5cda5f27763723acb307c0d22f.1737725820.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-24 14:37:58 +01:00
regmap: Split use_single_rw internally into use_single_read/write use_single_rw currently reflects the capabilities of the connected device. The capabilities of the bus are currently missing for this variable. As there are read only and write only buses we need seperate values for use_single_rw to also reflect tha capabilities of the bus. This patch splits use_single_rw into use_single_read and use_single_write. The initialization is changed to check the configuration for use_single_rw and to check the capabilities of the used bus. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-21 10:26:42 +02:00
regmap: fix comment for regmap.use_single_write Signed-off-by: David Frey <dpfrey@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-01 09:50:40 -07:00
regmap: Split use_single_rw internally into use_single_read/write use_single_rw currently reflects the capabilities of the connected device. The capabilities of the bus are currently missing for this variable. As there are read only and write only buses we need seperate values for use_single_rw to also reflect tha capabilities of the bus. This patch splits use_single_rw into use_single_read and use_single_write. The initialization is changed to check the configuration for use_single_rw and to check the capabilities of the used bus. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-21 10:26:42 +02:00
regmap: Implementation for regmap_multi_reg_write This is the implementation of regmap_multi_reg_write() There is a new capability 'can_multi_write' that device drivers must set in order to use this multi reg write mode. This replaces the first definition, which just defined the API. Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-03-04 13:54:02 +00:00
regmap: Add support for register indirect addressing. Devices with register paging or indirectly accessed registers can configure register mapping to map those on virtual address range. During access to virtually mapped register range, indirect addressing is processed automatically, in following steps: 1. selector for page or indirect register is updated (when needed); 2. register in data window is accessed. Configuration should provide minimum and maximum register for virtual range, details of selector field for page selection, minimum and maximum register of data window for indirect access. Virtual range registers are managed by cache as well as direct access registers. In order to make indirect access more efficient, selector register should be declared as non-volatile, if possible. struct regmap_config is extended with the following: struct regmap_range_cfg *ranges; unsigned int n_ranges; [Also reordered debugfs init to later on since the cleanup code was conflicting with the new cleanup code for ranges anyway -- broonie] Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-15 11:23:56 +01:00
regmap: Introduce max_raw_read/write for regmap_bulk_read/write 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-30 09:33:53 +02:00
regmap: Add support for register indirect addressing. Devices with register paging or indirectly accessed registers can configure register mapping to map those on virtual address range. During access to virtually mapped register range, indirect addressing is processed automatically, in following steps: 1. selector for page or indirect register is updated (when needed); 2. register in data window is accessed. Configuration should provide minimum and maximum register for virtual range, details of selector field for page selection, minimum and maximum register of data window for indirect access. Virtual range registers are managed by cache as well as direct access registers. In order to make indirect access more efficient, selector register should be declared as non-volatile, if possible. struct regmap_config is extended with the following: struct regmap_range_cfg *ranges; unsigned int n_ranges; [Also reordered debugfs init to later on since the cleanup code was conflicting with the new cleanup code for ranges anyway -- broonie] Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-15 11:23:56 +01:00
regmap: Add hardware spinlock support On some platforms, when reading or writing some special registers through regmap, we should acquire one hardware spinlock to synchronize between the multiple subsystems. Thus this patch adds the hardware spinlock support for regmap. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-01 10:11:55 +08:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regcache: Add ->populate() callback to separate from ->init() In the future changes we would like to change the flow of the cache handling. Add ->populate() callback in order to prepare for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20251031080540.3970776-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-31 09:03:16 +01:00
regmap: Fix regcache debugfs initialization Commit 6cfec04bcc05 ("regmap: Separate regmap dev initialization") moved the regmap debugfs initialization after regcache initialization. This means that the regmap debugfs directory is not created yet when the cache initialization runs and so any debugfs files registered by the regcache are created in the debugfs root directory rather than the debugfs directory of the regmap instance. Fix this by adding a separate callback for the regcache debugfs initialization which will be called after the parent debugfs entry has been created. Fixes: 6cfec04bcc05 (regmap: Separate regmap dev initialization) Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
2014-08-24 15:32:27 +02:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Supply ranges to the sync operations In order to allow us to support partial sync operations add minimum and maximum register arguments to the sync operation and update the rbtree and lzo caches to use this new information. The LZO implementation is obviously not good, we could exit the iteration earlier, but there may be room for more wide reaching optimisation there. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-23 19:31:04 +00:00
regmap: Add support for discarding parts of the register cache 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-05-08 13:55:22 +01:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00
regmap: Add a function to check if a regmap register is cached Add a function to check if a regmap register is cached. This will be used in debugfs to dump the cached values of write only registers. Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-08 18:44:21 +03:00
regmap: Add functions to check for access on registers We're going to be using these in quite a few places so factor out the readable/writable/volatile/precious checks. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-10 17:14:41 +09:00
regmap: Add regmap_noinc_write API The regmap API had a noinc_read function added for instances where devices supported returning data from an internal FIFO in a single read. This commit adds the noinc_write variant to allow writing to a non incrementing register, this is used in devices such as the sx1301 for loading firmware. Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-19 10:33:50 +01:00
regmap: Add regmap_noinc_read API The regmap API usually assumes that bulk read operations will read a range of registers but some I2C/SPI devices have certain registers for which a such a read operation will return data from an internal FIFO instead. Add an explicit API to support bulk read without range semantics. Some linux drivers use regmap_bulk_read or regmap_raw_read for such registers, for example mpu6050 or bmi150 from IIO. This only happens to work because when caching is disabled a single regmap read op will map to a single bus read op (as desired). This breaks if caching is enabled and reg+1 happens to be a cacheable register. Without regmap support refactoring a driver to enable regmap caching requires separate I2C and SPI paths. This is exactly what regmap is supposed to help avoid. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-07 17:52:17 +03:00
regmap: Add functions to check for access on registers We're going to be using these in quite a few places so factor out the readable/writable/volatile/precious checks. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-10 17:14:41 +09:00
regmap: Make _regmap_write() global Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-29 10:39:07 +01:00
regmap: Add support for register indirect addressing. Devices with register paging or indirectly accessed registers can configure register mapping to map those on virtual address range. During access to virtually mapped register range, indirect addressing is processed automatically, in following steps: 1. selector for page or indirect register is updated (when needed); 2. register in data window is accessed. Configuration should provide minimum and maximum register for virtual range, details of selector field for page selection, minimum and maximum register of data window for indirect access. Virtual range registers are managed by cache as well as direct access registers. In order to make indirect access more efficient, selector register should be declared as non-volatile, if possible. struct regmap_config is extended with the following: struct regmap_range_cfg *ranges; unsigned int n_ranges; [Also reordered debugfs init to later on since the cleanup code was conflicting with the new cleanup code for ranges anyway -- broonie] Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-15 11:23:56 +01:00
regmap: Allow ranges to be named For more useful diagnostics. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-10-03 12:40:47 +01:00
regmap: Provide debugfs read of register ranges If a register range is named then provide a debugfs file showing the contents of the range separately. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-10-03 13:13:16 +01:00
regmap: Add support for register indirect addressing. Devices with register paging or indirectly accessed registers can configure register mapping to map those on virtual address range. During access to virtually mapped register range, indirect addressing is processed automatically, in following steps: 1. selector for page or indirect register is updated (when needed); 2. register in data window is accessed. Configuration should provide minimum and maximum register for virtual range, details of selector field for page selection, minimum and maximum register of data window for indirect access. Virtual range registers are managed by cache as well as direct access registers. In order to make indirect access more efficient, selector register should be declared as non-volatile, if possible. struct regmap_config is extended with the following: struct regmap_range_cfg *ranges; unsigned int n_ranges; [Also reordered debugfs init to later on since the cleanup code was conflicting with the new cleanup code for ranges anyway -- broonie] Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-15 11:23:56 +01:00
regmap: Add regmap_field APIs 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-11 13:18:15 +01:00
regmap: Add regmap_fields APIs Current Linux kernel is supporting regmap_field method and it is very useful feature. It needs one regmap_filed for one register access. OTOH, there is multi port device which has many same registers in the market. The difference for each register access is only its address offset. Current API needs many regmap_field for such device, but it is not good. This patch adds new regmap_fileds API which can care about multi port/offset access via regmap. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-09-01 20:30:50 -07:00
regmap: Add regmap_field APIs 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-11 13:18:15 +01:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: debugfs: Fix handling of name string for debugfs init delays In regmap_debugfs_init the initialisation of the debugfs is delayed if the root node isn't ready yet. Most callers of regmap_debugfs_init pass the name from the regmap_config, which is considered temporary ie. may be unallocated after the regmap_init call returns. This leads to a potential use after free, where config->name has been freed by the time it is used in regmap_debugfs_initcall. This situation can be seen on Zynq, where the architecture init_irq callback registers a syscon device, using a local variable for the regmap_config. As init_irq is very early in the platform bring up the regmap debugfs root isn't ready yet. Although this doesn't crash it does result in the debugfs entry not having the correct name. Regmap already sets map->name from config->name on the regmap_init path and the fact that a separate field is used to pass the name to regmap_debugfs_init appears to be an artifact of the debugfs name being added before the map name. As such this patch updates regmap_debugfs_init to use map->name, which is already duplicated from the config avoiding the issue. This does however leave two lose ends, both regmap_attach_dev and regmap_reinit_cache can be called after a regmap is registered and would have had the effect of applying a new name to the debugfs entries. In both of these cases it was chosen to update the map name. In the case of regmap_attach_dev there are 3 users that currently use this function to update the name, thus doing so avoids changes for those users and it seems reasonable that attaching a device would want to set the name of the map. In the case of regmap_reinit_cache the primary use-case appears to be devices that need some register access to identify the device (for example devices in the same family) and then update the cache to match the exact hardware. Whilst no users do currently update the name here, given the use-case it seemed reasonable the name might want to be updated once the device is better identified. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200917120828.12987-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-17 13:08:28 +01:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: Disable debugfs when locking is disabled The recently added support for disabling the regmap internal locking left debugfs enabled for devices with the locking disabled. This is a problem since debugfs allows userspace to do things like initiate reads from the hardware which will use the scratch buffers protected by the regmap locking so could cause data corruption. For safety address this by just disabling debugfs for these devices. That is overly conservative since some of the debugfs files just read internal data structures but it's much simpler to implmement and less likely to lead to problems with tooling that works with debugfs. Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-12-12 16:56:43 +00:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: Make debugfs stubs static inline Make the debugfs stubs static inline to avoid future compilation issues due to duplicated symbols when CONFIG_DEBUG_FS=n once internal.h is included by multiple source files. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-05 22:06:13 +02:00
regmap: debugfs: Fix handling of name string for debugfs init delays In regmap_debugfs_init the initialisation of the debugfs is delayed if the root node isn't ready yet. Most callers of regmap_debugfs_init pass the name from the regmap_config, which is considered temporary ie. may be unallocated after the regmap_init call returns. This leads to a potential use after free, where config->name has been freed by the time it is used in regmap_debugfs_initcall. This situation can be seen on Zynq, where the architecture init_irq callback registers a syscon device, using a local variable for the regmap_config. As init_irq is very early in the platform bring up the regmap debugfs root isn't ready yet. Although this doesn't crash it does result in the debugfs entry not having the correct name. Regmap already sets map->name from config->name on the regmap_init path and the fact that a separate field is used to pass the name to regmap_debugfs_init appears to be an artifact of the debugfs name being added before the map name. As such this patch updates regmap_debugfs_init to use map->name, which is already duplicated from the config avoiding the issue. This does however leave two lose ends, both regmap_attach_dev and regmap_reinit_cache can be called after a regmap is registered and would have had the effect of applying a new name to the debugfs entries. In both of these cases it was chosen to update the map name. In the case of regmap_attach_dev there are 3 users that currently use this function to update the name, thus doing so avoids changes for those users and it seems reasonable that attaching a device would want to set the name of the map. In the case of regmap_reinit_cache the primary use-case appears to be devices that need some register access to identify the device (for example devices in the same family) and then update the cache to match the exact hardware. Whilst no users do currently update the name here, given the use-case it seemed reasonable the name might want to be updated once the device is better identified. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200917120828.12987-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-17 13:08:28 +01:00
regmap: Make debugfs stubs static inline Make the debugfs stubs static inline to avoid future compilation issues due to duplicated symbols when CONFIG_DEBUG_FS=n once internal.h is included by multiple source files. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-05 22:06:13 +02:00
regmap: Disable debugfs when locking is disabled The recently added support for disabling the regmap internal locking left debugfs enabled for devices with the locking disabled. This is a problem since debugfs allows userspace to do things like initiate reads from the hardware which will use the scratch buffers protected by the regmap locking so could cause data corruption. For safety address this by just disabling debugfs for these devices. That is overly conservative since some of the debugfs files just read internal data structures but it's much simpler to implmement and less likely to lead to problems with tooling that works with debugfs. Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-12-12 16:56:43 +00:00
regmap: Provide register map dump via debugfs Copy over the read parts of the ASoC debugfs implementation into regmap, allowing users to see what the register values the device has are at runtime. The implementation, especially the support for seeking, is mostly due to Dimitris Papastamos' work in ASoC. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:56:53 +01:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Move initialization of regcache related fields to regcache_init Move the initialization regcache related fields of the regmap struct to regcache_init. This allows us to keep regmap and regcache code better separated. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-11-16 16:28:16 +01:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: cache: Factor out block sync 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-29 19:32:28 +00:00
regmap: rbtree: Make cache_present bitmap per node With devices which have a dense and small register map but placed at a large offset the global cache_present bitmap imposes a huge memory overhead. Making the cache_present per rbtree node avoids the issue and easily reduces the memory footprint by a factor of ten. For devices with a more sparse map or without a large base register offset the memory usage might increase slightly by a few bytes, but not significantly. E.g. for a device which has ~50 registers at offset 0x4000 the memory footprint of the register cache goes down form 2496 bytes to 175 bytes. Moving the bitmap to a per node basis means that the handling of the bitmap is now cache implementation specific and can no longer be managed by the core. The regcache_sync_block() function is extended by a additional parameter so that the cache implementation can tell the core which registers in the block are set and which are not. The parameter is optional and if NULL the core assumes that all registers are set. The rbtree cache also needs to implement its own drop callback instead of relying on the core to handle this. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-29 10:26:34 +02:00
regmap: cache: Factor out block sync 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-29 19:32:28 +00:00
regmap: maple: Implement block sync for the maple tree cache For register maps where we can write multiple values in a single bus operation it is generally much faster to do so. Improve the performance of maple tree cache syncs on such devices by identifying blocks of adjacent registers that need to be written out and combining them into a single operation. Combining writes does mean that we need to allocate a scratch buffer and format the data into it but it is expected that for most cases where caches are in use the cost of I/O will be much greater than the cost of doing the allocation and format. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-regcache-maple-sync-raw-v1-1-8ddeb4e2b9ab@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-11 13:06:07 +01:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: cache: Provide a get address of value operation 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-13 19:29:36 +00:00
regmap: cache: Pass the map rather than the word size when updating values It's more idiomatic to pass the map structure around and this means we can use other bits of information from the map. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-21 18:03:13 +00:00
regmap: Don't check for changes in regcache_set_val() The only user of regcache_set_val() ignores the return value so we may as well not bother checking if the value we are trying to set is the same as the value already stored. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-regcache-set-val-no-ret-v1-1-9a6932760cf8@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-10 15:05:54 +01:00
regmap: cache: Pass the map rather than the word size when updating values It's more idiomatic to pass the map structure around and this means we can use other bits of information from the map. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-21 18:03:13 +00:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: Factor out single value register syncing In order to support sparse caches that don't store data in raw format factor out the parts of the raw block sync implementation that deal with writing a single register via _regmap_write(). Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230325-regcache-maple-v3-1-23e271f93dc7@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-30 01:10:23 +01:00
regmap: Introduce caching support This patch introduces caching support for regmap. The regcache API has evolved essentially out of ASoC soc-cache so most of the actual caching types (except LZO) have been tested in the past. The purpose of regcache is to optimize in time and space the handling of register caches. Time optimization is achieved by not having to go over a slow bus like I2C to read the value of a register, instead it is cached locally in memory and can be retrieved faster. Regarding space optimization, some of the cache types are better at packing the caches, for e.g. the rbtree and the LZO caches. By doing this the sacrifice in time still wins over doing I2C transactions. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:00 +01:00
regmap: core: Make raw write available to regcache 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-13 19:19:34 +00:00
regmap: fix page selection for noinc writes Non-incrementing writes can fail if register + length crosses page border. However for non-incrementing writes we should not check for page border crossing. Fix this by passing additional flag to _regmap_raw_write and passing length to _regmap_select_page basing on the flag. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API") Link: https://lore.kernel.org/r/20200917153405.3139200-2-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-17 18:34:05 +03:00
regmap: core: Make raw write available to regcache 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-13 19:19:34 +00:00
regmap: Add asynchronous I/O support Some use cases like firmware download can transfer a lot of data in quick succession. With high speed buses these use cases can benefit from having multiple transfers scheduled at once since this allows the bus to minimise the delay between transfers. Support this by adding regmap_raw_write_async(), allowing raw transfers to be scheduled, and regmap_async_complete() to wait for them to finish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 22:07:38 +08:00
regmap: Export regmap_get_val_endian We'll need to call it from regmap-i2c.c, which can be built as module. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-03 10:01:18 -08:00
regmap: add flat cache with sparse validity The flat regcache will always assume the data in the cache is valid. Since the cache is preferred over hardware access, this may shadow the actual state of the device. Add a new containing cache structure with the flat data table and a bitmap indicating cache validity. REGCACHE_FLAT will still behave as before, as the validity is ignored. Define new cache type REGCACHE_FLAT_S: a flat cache with sparse validity. The sparse validity is used to determine if a hardware access should occur to initialize the cache on the fly, vs. at regmap init for REGCACHE_FLAT. Contrary to REGCACHE_FLAT, this allows us to implement regcache_ops.drop. Signed-off-by: Sander Vanheule <sander@svanheule.net> Link: https://patch.msgid.link/20251029081248.52607-2-sander@svanheule.net Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-29 09:12:47 +01:00
regmap: Add the rbtree cache support This patch adds support for the rbtree cache compression type. Each rbnode manages a variable length block of registers. There can be no two nodes with overlapping blocks. Each block has a base register and a currently top register, all the other registers, if any, lie in between these two and in ascending order. The reasoning behind the construction of this rbtree is simple. In the snd_soc_rbtree_cache_init() function, we iterate over the register defaults provided by the regcache core. For each register value that is non-zero we insert it in the rbtree. In order to determine in which rbnode we need to add the register, we first look if there is another register already added that is adjacent to the one we are about to add. If that is the case we append it in that rbnode block, otherwise we create a new rbnode with a single register in its block and add it to the tree. There are various optimizations across the implementation to speed up lookups by caching the most recently used rbnode. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:02 +01:00
regmap: Add maple tree based register cache The current state of the art for sparse register maps is the rbtree cache. This works well for most applications but isn't always ideal for sparser register maps since the rbtree can get deep, requiring a lot of walking. Fortunately the kernel has a data structure intended to address this very problem, the maple tree. Provide an initial implementation of a register cache based on the maple tree to start taking advantage of it. The entries stored in the maple tree are arrays of register values, with the maple tree keys holding the register addresses. We store data in host native format rather than device native format as we do for rbtree, this will be a benefit for devices where we don't marshal data within regmap and simplifies the code but will result in additional CPU overhead when syncing the cache on devices where we do marshal data in regmap. This should work well for a lot of devices, though there's some additional areas that could be looked at such as caching the last accessed entry like we do for rbtree and trying to minimise the maple tree level locking. We should also use bulk writes rather than single register writes when resyncing the cache where possible, even if we don't store in device native format. Very small register maps may continue to to better with rbtree longer term. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230325-regcache-maple-v3-2-23e271f93dc7@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-30 01:10:24 +01:00
regmap: flat: Add flat cache type While for I2C and SPI devices the overhead of using rbtree for devices with only one block of registers is negligible the same isn't always going to be true for MMIO devices where the I/O costs are very much lower. Cater for these devices by adding a simple flat array type for them where the lookups are simple array accesses, taking us right back to the original ASoC cache implementation. Thanks to Magnus Damm for the discussion which prompted this. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-19 14:51:55 +00:00
regmap: Add the LZO cache support This patch adds support for LZO compression when storing the register cache. For a typical device whose register map would normally occupy 25kB or 50kB by using the LZO compression technique, one can get down to ~5-7kB. There might be a performance penalty associated with each individual read/write due to decompressing/compressing the underlying cache, however that should not be noticeable. These memory benefits depend on whether the target architecture can get rid of the memory occupied by the original register defaults cache which is marked as __devinitconst. Nevertheless there will be some memory gain even if the target architecture can't get rid of the original register map, this should be around ~30-32kB instead of 50kB. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 14:34:03 +01:00
regmap: introduce regmap_name to fix syscon regmap trace events This patch fixes a NULL pointer dereference when enabling regmap event tracing in the presence of a syscon regmap, introduced by commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices"). That patch introduced syscon regmaps that have their dev field set to NULL. The regmap trace events expect it to point to a valid struct device and feed it to dev_name(): $ echo 1 > /sys/kernel/debug/tracing/events/regmap/enable Unable to handle kernel NULL pointer dereference at virtual address 0000002c pgd = 80004000 [0000002c] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: coda videobuf2_vmalloc CPU: 0 PID: 304 Comm: kworker/0:2 Not tainted 4.0.0-rc2+ #9197 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events_freezable thermal_zone_device_check task: 9f25a200 ti: 9f1ee000 task.ti: 9f1ee000 PC is at ftrace_raw_event_regmap_block+0x3c/0xe4 LR is at _regmap_raw_read+0x1bc/0x1cc pc : [<803636e8>] lr : [<80365f2c>] psr: 600f0093 sp : 9f1efd78 ip : 9f1efdb8 fp : 9f1efdb4 r10: 00000004 r9 : 00000001 r8 : 00000001 r7 : 00000180 r6 : 00000000 r5 : 9f00e3c0 r4 : 00000003 r3 : 00000001 r2 : 00000180 r1 : 00000000 r0 : 9f00e3c0 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 2d91004a DAC: 00000015 Process kworker/0:2 (pid: 304, stack limit = 0x9f1ee210) Stack: (0x9f1efd78 to 0x9f1f0000) fd60: 9f1efda4 9f1efd88 fd80: 800708c0 805f9510 80927140 800f0013 9f1fc800 9eb2f490 00000000 00000180 fda0: 808e3840 00000001 9f1efdfc 9f1efdb8 80365f2c 803636b8 805f8958 800708e0 fdc0: a00f0013 803636ac 9f16de00 00000180 80927140 9f1fc800 9f1fc800 9f1efe6c fde0: 9f1efe6c 9f732400 00000000 00000000 9f1efe1c 9f1efe00 80365f70 80365d7c fe00: 80365f3c 9f1fc800 9f1fc800 00000180 9f1efe44 9f1efe20 803656a4 80365f48 fe20: 9f1fc800 00000180 9f1efe6c 9f1efe6c 9f732400 00000000 9f1efe64 9f1efe48 fe40: 803657bc 80365634 00000001 9e95f910 9f1fc800 9f1efeb4 9f1efe8c 9f1efe68 fe60: 80452ac0 80365778 9f1efe8c 9f1efe78 9e93d400 9e93d5e8 9f1efeb4 9f72ef40 fe80: 9f1efeac 9f1efe90 8044e11c 80452998 8045298c 9e93d608 9e93d400 808e1978 fea0: 9f1efecc 9f1efeb0 8044fd14 8044e0d0 ffffffff 9f25a200 9e93d608 9e481380 fec0: 9f1efedc 9f1efed0 8044fde8 8044fcec 9f1eff1c 9f1efee0 80038d50 8044fdd8 fee0: 9f1ee020 9f72ef40 9e481398 00000000 00000008 9f72ef54 9f1ee020 9f72ef40 ff00: 9e481398 9e481380 00000008 9f72ef40 9f1eff5c 9f1eff20 80039754 80038bfc ff20: 00000000 9e481380 80894100 808e1662 00000000 9e4f2ec0 00000000 9e481380 ff40: 800396f8 00000000 00000000 00000000 9f1effac 9f1eff60 8003e020 80039704 ff60: ffffffff 00000000 ffffffff 9e481380 00000000 00000000 9f1eff78 9f1eff78 ff80: 00000000 00000000 9f1eff88 9f1eff88 9e4f2ec0 8003df30 00000000 00000000 ffa0: 00000000 9f1effb0 8000eb60 8003df3c 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff Backtrace: [<803636ac>] (ftrace_raw_event_regmap_block) from [<80365f2c>] (_regmap_raw_read+0x1bc/0x1cc) r9:00000001 r8:808e3840 r7:00000180 r6:00000000 r5:9eb2f490 r4:9f1fc800 [<80365d70>] (_regmap_raw_read) from [<80365f70>] (_regmap_bus_read+0x34/0x6c) r10:00000000 r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:9f1fc800 r4:9f1fc800 [<80365f3c>] (_regmap_bus_read) from [<803656a4>] (_regmap_read+0x7c/0x144) r6:00000180 r5:9f1fc800 r4:9f1fc800 r3:80365f3c [<80365628>] (_regmap_read) from [<803657bc>] (regmap_read+0x50/0x70) r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:00000180 r4:9f1fc800 [<8036576c>] (regmap_read) from [<80452ac0>] (imx_get_temp+0x134/0x1a4) r6:9f1efeb4 r5:9f1fc800 r4:9e95f910 r3:00000001 [<8045298c>] (imx_get_temp) from [<8044e11c>] (thermal_zone_get_temp+0x58/0x74) r7:9f72ef40 r6:9f1efeb4 r5:9e93d5e8 r4:9e93d400 [<8044e0c4>] (thermal_zone_get_temp) from [<8044fd14>] (thermal_zone_device_update+0x34/0xec) r6:808e1978 r5:9e93d400 r4:9e93d608 r3:8045298c [<8044fce0>] (thermal_zone_device_update) from [<8044fde8>] (thermal_zone_device_check+0x1c/0x20) r5:9e481380 r4:9e93d608 [<8044fdcc>] (thermal_zone_device_check) from [<80038d50>] (process_one_work+0x160/0x3d4) [<80038bf0>] (process_one_work) from [<80039754>] (worker_thread+0x5c/0x4f4) r10:9f72ef40 r9:00000008 r8:9e481380 r7:9e481398 r6:9f72ef40 r5:9f1ee020 r4:9f72ef54 [<800396f8>] (worker_thread) from [<8003e020>] (kthread+0xf0/0x108) r10:00000000 r9:00000000 r8:00000000 r7:800396f8 r6:9e481380 r5:00000000 r4:9e4f2ec0 [<8003df30>] (kthread) from [<8000eb60>] (ret_from_fork+0x14/0x34) r7:00000000 r6:00000000 r5:8003df30 r4:9e4f2ec0 Code: e3140040 1a00001a e3140020 1a000016 (e596002c) ---[ end trace 193c15c2494ec960 ]--- Fixes: bdb0066df96e (mfd: syscon: Decouple syscon interface from platform devices) Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-03-09 12:20:13 +01:00
regmap: core: Introduce register stride order Since the register stride should always equal to 2^N, and bit rotation is much faster than multiplication and division. So introducing the stride order and using bit rotation to get the offset of the register from the index to improve the performance. Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-04 18:00:33 +08:00
regcache: Introduce the index parsing API by stride order Here introduces regcache_get_index_by_order() for regmap cache, which uses the register stride order and bit rotation, to improve the performance. Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-04 18:00:34 +08:00
regmap: Add RAM backed register map Add a register map that is a simple array of memory, for use in KUnit testing of the framework. This is not exposed in regmap.h since I can't think of a non-test use case, it is purely for use internally. To facilitate testing we track if registers have been read or written to. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230324-regmap-kunit-v2-1-b208801dc2c8@kernel.org
2023-03-26 15:11:12 +01:00
regmap: Provide a ram backed regmap with raw support Provide a simple, 16 bit only, RAM backed regmap which supports raw I/O for use in testing. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230610-regcache-raw-kunit-v1-1-583112cd28ac@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-11 14:25:02 +01:00
regmap: ram: support noinc semantics Support noinc semantics in RAM backed regmaps, for testing purposes. Add a new callback that selects registers which should have noinc behavior. Bulk writes to a noinc register will cause the last value in the buffer to be assigned to the register, while bulk reads will copy the same value repeatedly into the buffer. This patch only adds support to regmap-raw-ram, since regmap-ram does not support bulk operations. Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com> Link: https://lore.kernel.org/r/20231102203039.3069305-1-ben.wolsieffer@hefring.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-11-02 16:30:38 -04:00
regmap: Add RAM backed register map Add a register map that is a simple array of memory, for use in KUnit testing of the framework. This is not exposed in regmap.h since I can't think of a non-test use case, it is purely for use internally. To facilitate testing we track if registers have been read or written to. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230324-regmap-kunit-v2-1-b208801dc2c8@kernel.org
2023-03-26 15:11:12 +01:00
regmap: kunit: Create a struct device for the regmap Use kunit_device_register() to create a real struct device for the regmap instead of leaving it at NULL. The main reason for this is that it allows context data to be passed into the readable_reg/writable_reg/volatile_reg functions by attaching it to the struct device with dev_set_drvdata(). The gen_regmap() and gen_raw_regmap() functions are updated to take a struct kunit * argument. A new struct regmap_test_priv has been created to hold the struct device created by kunit_device_register(). This allows the struct to be extended in the future to hold more private data for the test suite. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://msgid.link/r/20240408144600.230848-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-08 15:45:51 +01:00
regmap: Add RAM backed register map Add a register map that is a simple array of memory, for use in KUnit testing of the framework. This is not exposed in regmap.h since I can't think of a non-test use case, it is purely for use internally. To facilitate testing we track if registers have been read or written to. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230324-regmap-kunit-v2-1-b208801dc2c8@kernel.org
2023-03-26 15:11:12 +01:00
regmap: kunit: Create a struct device for the regmap Use kunit_device_register() to create a real struct device for the regmap instead of leaving it at NULL. The main reason for this is that it allows context data to be passed into the readable_reg/writable_reg/volatile_reg functions by attaching it to the struct device with dev_set_drvdata(). The gen_regmap() and gen_raw_regmap() functions are updated to take a struct kunit * argument. A new struct regmap_test_priv has been created to hold the struct device created by kunit_device_register(). This allows the struct to be extended in the future to hold more private data for the test suite. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://msgid.link/r/20240408144600.230848-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-08 15:45:51 +01:00
regmap: Add RAM backed register map Add a register map that is a simple array of memory, for use in KUnit testing of the framework. This is not exposed in regmap.h since I can't think of a non-test use case, it is purely for use internally. To facilitate testing we track if registers have been read or written to. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230324-regmap-kunit-v2-1-b208801dc2c8@kernel.org
2023-03-26 15:11:12 +01:00
regmap: kunit: Create a struct device for the regmap Use kunit_device_register() to create a real struct device for the regmap instead of leaving it at NULL. The main reason for this is that it allows context data to be passed into the readable_reg/writable_reg/volatile_reg functions by attaching it to the struct device with dev_set_drvdata(). The gen_regmap() and gen_raw_regmap() functions are updated to take a struct kunit * argument. A new struct regmap_test_priv has been created to hold the struct device created by kunit_device_register(). This allows the struct to be extended in the future to hold more private data for the test suite. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://msgid.link/r/20240408144600.230848-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-08 15:45:51 +01:00
regmap: Provide a ram backed regmap with raw support Provide a simple, 16 bit only, RAM backed regmap which supports raw I/O for use in testing. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230610-regcache-raw-kunit-v1-1-583112cd28ac@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-11 14:25:02 +01:00
regmap: kunit: Create a struct device for the regmap Use kunit_device_register() to create a real struct device for the regmap instead of leaving it at NULL. The main reason for this is that it allows context data to be passed into the readable_reg/writable_reg/volatile_reg functions by attaching it to the struct device with dev_set_drvdata(). The gen_regmap() and gen_raw_regmap() functions are updated to take a struct kunit * argument. A new struct regmap_test_priv has been created to hold the struct device created by kunit_device_register(). This allows the struct to be extended in the future to hold more private data for the test suite. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://msgid.link/r/20240408144600.230848-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-08 15:45:51 +01:00
regmap: Add RAM backed register map Add a register map that is a simple array of memory, for use in KUnit testing of the framework. This is not exposed in regmap.h since I can't think of a non-test use case, it is purely for use internally. To facilitate testing we track if registers have been read or written to. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230324-regmap-kunit-v2-1-b208801dc2c8@kernel.org
2023-03-26 15:11:12 +01:00
regmap: Use a local header for API internals Allowing the implementation to be multi-file. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:35:37 +01:00