kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/include/linux/regmap.h

2125 lines
73 KiB
Raw Permalink Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04 10:11:33 +02:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +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: include <linux/ktime.h> from include/linux/regmap.h Similar to the readx_poll_timeout() macro calling ktime_* and using ktime_t type, which is declared in <linux/ktime.h>. So, make include/linux/regmap.h explicitly include <linux/ktime.h>, like include/linux/iopoll.h does. Otherwise, users of the macro will see below errors. error: implicit declaration of function ‘ktime_add_us’ [-Werror=implicit-function-declaration] error: implicit declaration of function ‘ktime_get’ [-Werror=implicit-function-declaration] error: implicit declaration of function ‘ktime_compare’ [-Werror=implicit-function-declaration] include/linux/regmap.h:128:2: error: unknown type name ‘ktime_t’ ktime_t __timeout = ktime_add_us(ktime_get(), __timeout_us); \ Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-23 14:42:44 +08:00
regmap: include <linux/delay.h> from include/linux/regmap.h The readx_poll_timeout() macro calls usleep_range(), which is declared in <linux/delay.h>. Make include/linux/regmap.h include <linux/delay.h>, like include/linux/iopoll.h does. Otherwise, users of the macro will see "implicit declaration of function 'usleep_range'" error. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-10-13 19:07:54 +09:00
regmap: Add missing header for !CONFIG_REGMAP stubs regmap.h requires linux/err.h if CONFIG_REGMAP is not defined. Without it I get error. CC drivers/media/platform/exynos4-is/fimc-reg.o In file included from drivers/media/platform/exynos4-is/fimc-reg.c:14:0: include/linux/regmap.h: In function ‘regmap_write’: include/linux/regmap.h:525:10: error: ‘EINVAL’ undeclared (first use in this function) include/linux/regmap.h:525:10: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Mateusz Krawczuk <m.krawczuk@partner.samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@kernel.org
2013-08-06 18:34:40 +02:00
regmap: Add another missing header for !CONFIG_REGMAP stubs The use of WARN_ON() needs the definitions from bug.h, without it you can get: include/linux/regmap.h: In function 'regmap_write': include/linux/regmap.h:525:2: error: implicit declaration of function 'WARN_ONCE' [-Werror=implicit-function-declaration] Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
2013-08-14 16:05:02 -07:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Simplify implementation of the regmap_read_poll_timeout() macro Simplify the implementation of the macro regmap_read_poll_timeout() by using the macro read_poll_timeout(). Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Link: https://lore.kernel.org/r/20200420134647.9121-2-zhengdejin5@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-20 21:46:46 +08:00
regmap-irq: use fwnode instead of device node in add_irq_chip() Convert the argument to the newer fwnode_handle instead a device tree node. Fortunately, there are no users for now. So this is an easy change. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200706175353.16404-2-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-06 19:53:41 +02:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
include: replace linux/module.h with "struct module" wherever possible The <linux/module.h> pretty much brings in the kitchen sink along with it, so it should be avoided wherever reasonably possible in terms of being included from other commonly used <linux/something.h> files, as it results in a measureable increase on compile times. The worst culprit was probably device.h since it is used everywhere. This file also had an implicit dependency/usage of mutex.h which was masked by module.h, and is also fixed here at the same time. There are over a dozen other headers that simply declare the struct instead of pulling in the whole file, so follow their lead and simply make it a few more. Most of the implicit dependencies on module.h being present by these headers pulling it in have been now weeded out, so we can finally make this change with hopefully minimal breakage. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-26 13:46:22 -04:00
regmap: mmio: Add function to attach a clock regmap_init_mmio_clk allows to specify a clock that needs to be enabled while accessing the registers. However, that clock is retrieved through its clock ID, which means it will lookup that clock based on the current device that registers the regmap, and, in the DT case, will only look in that device OF node. This might be problematic if the clock to enable is stored in another node. Let's add a function that allows to attach a clock that has already been retrieved to a regmap in order to fix this. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-21 10:20:25 +01:00
device.h: audit and cleanup users in main include dir The <linux/device.h> header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-01-30 11:46:54 -05:00
regmap-irq: make it possible to add irq_chip do a specific device node Add a new function regmap_add_irq_chip_np() with its corresponding devm_regmap_add_irq_chip_np() variant. Sometimes one want to register the IRQ domain on a different device node that the one of the regmap node. For example when using a MFD where there are different interrupt controllers and particularly for the generic regmap gpio_chip/irq_chip driver. In this case it is not desireable to have the IRQ domain on the parent node. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200402203656.27047-5-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-02 22:36:44 +02:00
regmap: Add FSI bus support Add regmap support for the FSI bus. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20221102205148.1334459-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-02 15:51:44 -05:00
regmap: Add I2C bus support Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-06-20 19:02:29 +01:00
regmap: add i3c bus support Add basic support for i3c bus. This is a simple implementation that only give support for SDR Read and Write commands. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06 17:12:02 +02:00
regmap: irq: Allow users to retrieve the irq_domain This is useful for integration with other subsystems, especially MFD, and provides an alternative API for users that request their own IRQs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-20 21:45:05 +01:00
regmap: Add MDIO bus support Basic support for MDIO bus access. Support only includes clause-22 register access, with 5-bit addresses, and 16-bit wide registers. Signed-off-by: Sander Vanheule <sander@svanheule.net> Link: https://lore.kernel.org/r/63b99a2fec2c4ea3c461d59d451af8d675ecf312.1621279162.git.sander@svanheule.net Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-17 21:28:03 +02:00
regmap: add SLIMbus support This patch adds support to read/write SLIMbus value elements. Currently it only supports byte read/write. Adding this support in regmap would give codec drivers more flexibility when there are more than 2 control interfaces like SLIMbus, i2c. Without this patch each codec driver has to directly call SLIMbus value element apis, and this could would get messy once we want to add i2c interface to it. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviwed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-11 23:43:02 +00:00
regmap: Add SPI bus support Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-12 11:42:10 +02:00
regmap: add SPMI support Add basic support for the System Power Management Interface (SPMI) bus. This is a simple implementation which only implements register accesses via the Extended Register Read/Write Long commands. Signed-off-by: Josh Cartwright <joshc@codeaurora.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-28 13:12:35 -05:00
regmap: Rejig struct declarations for stubbed API Ensure we have a forward declaration of struct regmap that isn't just the return value of regmap_init() and make the definition of the register defaults available. Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-11 11:49:17 +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: 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: ac97: Add generic AC'97 callbacks Use the recently added support for bus operations to provide a standard mapping for AC'97 register I/O. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2014-11-18 19:45:51 +01:00
regmap: Add SoundWire bus support SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-08 15:50:59 +05:30
regmap: Add I2C bus support Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-06-20 19:02:29 +01:00
regmap: Rework regmap_mdio_c45_{read|write} for new C45 API. The MDIO subsystem is getting rid of MII_ADDR_C45 and thus also encoding associated encoding of the C45 device address and register address into one value. regmap-mdio also uses this encoding for the C45 bus. Move to the new C45 helpers for MDIO access and provide regmap-mdio helper macros. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20230116111509.4086236-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-16 12:15:09 +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
regcache: Improve documentation of available cache types There is some user confusion about which cache types to choose when which is not helped by the lack of any central documentation providing an overview of what's available. Provide a short overview in the API header to try to help reduce this. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20240924-regcache-document-types-v1-1-e157054e1215@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-24 12:08:08 +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: 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: 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 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: 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: Allow drivers to specify register defaults It is useful for the register cache code to be able to specify the default values for the device registers. The major use is when restoring the register cache after suspend, knowing the register defaults allows us to skip registers that are at their default values when we resume which can be a substantial win on larger modern devices. For some devices (mostly older ones) the hardware does not support readback so the only way we can know the values is from code and so initializing the cache with default values makes it much easier for drivers work with read/modify/write updates. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-19 18:09:38 +09:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Allow drivers to specify register defaults It is useful for the register cache code to be able to specify the default values for the device registers. The major use is when restoring the register cache after suspend, knowing the register defaults allows us to skip registers that are at their default values when we resume which can be a substantial win on larger modern devices. For some devices (mostly older ones) the hardware does not support readback so the only way we can know the values is from code and so initializing the cache with default values makes it much easier for drivers work with read/modify/write updates. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-19 18:09:38 +09:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Allow drivers to specify register defaults It is useful for the register cache code to be able to specify the default values for the device registers. The major use is when restoring the register cache after suspend, knowing the register defaults allows us to skip registers that are at their default values when we resume which can be a substantial win on larger modern devices. For some devices (mostly older ones) the hardware does not support readback so the only way we can know the values is from code and so initializing the cache with default values makes it much easier for drivers work with read/modify/write updates. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-19 18:09:38 +09: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
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +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
regmap: Apply optional delay in multi_reg_write/register_patch Add an optional delay_us field in reg_sequence to allow the client to specify a delay (in microseconds) to be applied after any given write in a sequence of writes. We treat a delay in a sequence the same way we treat a page change as they are logically similar in that you can coalesce all write before a delay (in the same way you can coalesce all writes before a page change is needed) Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-16 16:36:22 +01:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +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
regmap: Apply optional delay in multi_reg_write/register_patch Add an optional delay_us field in reg_sequence to allow the client to specify a delay (in microseconds) to be applied after any given write in a sequence of writes. We treat a delay in a sequence the same way we treat a page change as they are logically similar in that you can coalesce all write before a delay (in the same way you can coalesce all writes before a page change is needed) Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-16 16:36:22 +01: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
regmap: add reg_sequence helpers Add helper to make it easier to define a reg_sequence array. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20200402084111.30123-1-m.felsch@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-02 10:41:11 +02:00
regmap: add iopoll-like polling macro This patch adds a macro regmap_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_read. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-06 16:19:41 +02:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: add iopoll-like polling macro This patch adds a macro regmap_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_read. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-06 16:19:41 +02:00
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
2024-10-14 10:22:29 +02:00
regmap: add iopoll-like polling macro This patch adds a macro regmap_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_read. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-06 16:19:41 +02:00
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
2024-10-14 10:22:29 +02:00
regmap: add iopoll-like polling macro This patch adds a macro regmap_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_read. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-06 16:19:41 +02:00
regmap: Simplify implementation of the regmap_read_poll_timeout() macro Simplify the implementation of the macro regmap_read_poll_timeout() by using the macro read_poll_timeout(). Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Link: https://lore.kernel.org/r/20200420134647.9121-2-zhengdejin5@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-20 21:46:46 +08:00
regmap: add iopoll-like polling macro This patch adds a macro regmap_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_read. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-06 16:19:41 +02:00
regmap: add iopoll-like atomic polling macro This patch adds a macro 'regmap_read_poll_timeout_atomic' that works similar to 'readx_poll_timeout_atomic' defined in linux/iopoll.h; This is atomic version of already available 'regmap_read_poll_timeout' macro. It should be noted that above atomic macro cannot be used by all regmaps. If the regmap is set up for atomic use (flat or no cache and MMIO) then only it can use. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1578546590-24737-1-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09 10:39:50 +05:30
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
2024-10-14 10:22:29 +02:00
regmap: add iopoll-like atomic polling macro This patch adds a macro 'regmap_read_poll_timeout_atomic' that works similar to 'readx_poll_timeout_atomic' defined in linux/iopoll.h; This is atomic version of already available 'regmap_read_poll_timeout' macro. It should be noted that above atomic macro cannot be used by all regmaps. If the regmap is set up for atomic use (flat or no cache and MMIO) then only it can use. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1578546590-24737-1-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09 10:39:50 +05:30
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
2024-10-14 10:22:29 +02:00
regmap: add iopoll-like atomic polling macro This patch adds a macro 'regmap_read_poll_timeout_atomic' that works similar to 'readx_poll_timeout_atomic' defined in linux/iopoll.h; This is atomic version of already available 'regmap_read_poll_timeout' macro. It should be noted that above atomic macro cannot be used by all regmaps. If the regmap is set up for atomic use (flat or no cache and MMIO) then only it can use. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1578546590-24737-1-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09 10:39:50 +05:30
regmap: add iopoll-like polling macro for regmap_field This patch adds a macro regmap_field_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_field_read. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-09-29 16:23:01 +08:00
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
2024-10-14 10:22:29 +02:00
regmap: add iopoll-like polling macro for regmap_field This patch adds a macro regmap_field_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_field_read. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-09-29 16:23:01 +08:00
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
2024-10-14 10:22:29 +02:00
regmap: add iopoll-like polling macro for regmap_field This patch adds a macro regmap_field_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_field_read. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-09-29 16:23:01 +08:00
regmap: Simplify implementation of the regmap_field_read_poll_timeout() macro Simplify the implementation of the macro regmap_field_read_poll_timeout() by using the macro read_poll_timeout(). Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Link: https://lore.kernel.org/r/20200420134647.9121-3-zhengdejin5@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-20 21:46:47 +08:00
regmap: add iopoll-like polling macro for regmap_field This patch adds a macro regmap_field_read_poll_timeout that works similar to the readx_poll_timeout defined in linux/iopoll.h, except that this can also return the error value returned by a failed regmap_field_read. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-09-29 16:23:01 +08:00
regmap: Rejig struct declarations for stubbed API Ensure we have a forward declaration of struct regmap that isn't just the return value of regmap_init() and make the definition of the register defaults available. Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-11 11:49:17 +00:00
regmap: allow busses to request formatting with specific endianness Add a field to struct regmap_bus that allows bus drivers to request that register addresses and values be formatted with a specific endianness. The default endianness is unchanged from current operation: Big. Implement native endian formatting/parsing for 16- and 32-bit values. This will be enough to support regmap-mmio.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-24 10:47:26 -06: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: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00: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 helper macro to set min/max range of register Add helper macro to set the min and max value of the register range. This is useful when initialising the register ranges of the device like static const struct regmap_range readable_ranges[] = { regmap_reg_range(DEVICE_REG0, DEVICE_REG10), }; Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-09-20 18:00:10 +05:30
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00: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: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00: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: 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: Add kerneldoc for struct regmap_config Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:28:58 +01:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Add kerneldoc for struct regmap_config Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:28:58 +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: Add kerneldoc for struct regmap_config Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:28:58 +01: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: 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: 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: 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: Add kerneldoc for struct regmap_config Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:28:58 +01:00
regmap: Allow devices to specify which registers are accessible This is currently unused but we need to know which registers exist and their properties in order to implement diagnostics like register map dumps and the cache features. We use callbacks partly because properties can vary at runtime (eg, through access locks on registers) and partly because big switch statements are a good compromise between readable code and small data size for providing information on big register maps. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:33:39 +01:00
regmap: Fix kerneldoc errors for regmap Field names didn't match between the documentation and the code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-09 10:23:22 +09: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: Fix kerneldoc errors for regmap Field names didn't match between the documentation and the code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-09 10:23:22 +09: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: Fix kerneldoc errors for regmap Field names didn't match between the documentation and the code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-09 10:23:22 +09: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: fix a couple of typos These sentences are not proper English due to the typos. I had initially caught one of them while trying to understand the regmap feature, and then I just ran the vim spell checker, and went through all the items that would need to be fixed for this header file. Signed-off-by: Laszlo Papp <lpapp@kde.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-01-09 14:13:41 +00: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: fix a couple of typos These sentences are not proper English due to the typos. I had initially caught one of them while trying to understand the regmap feature, and then I just ran the vim spell checker, and went through all the items that would need to be fixed for this header file. Signed-off-by: Laszlo Papp <lpapp@kde.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-01-09 14:13:41 +00: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 "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: fix a couple of typos These sentences are not proper English due to the typos. I had initially caught one of them while trying to understand the regmap feature, and then I just ran the vim spell checker, and went through all the items that would need to be fixed for this header file. Signed-off-by: Laszlo Papp <lpapp@kde.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-01-09 14:13:41 +00:00
regmap: Add "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: allow to define reg_update_bits for no bus configuration Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a dedicated function in regmap_config for reg_update_bits in no bus configuration. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-04 16:00:40 +01: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: Reorder fields in 'struct regmap_config' to save some memory On x86_64 and allmodconfig, this shrinks the size of 'struct regmap_config' from 328 to 312 bytes. This is usually a win, because this structure is used as a static global variable. When moving the kerneldoc fields, I've tried to keep the layout as consistent as possible, which is not really easy! Before: /* size: 328, cachelines: 6, members: 55 */ /* sum members: 296, holes: 6, sum holes: 25 */ /* padding: 7 */ /* last cacheline: 8 bytes */ After: /* size: 312, cachelines: 5, members: 55 */ /* sum members: 296, holes: 5, sum holes: 16 */ /* last cacheline: 56 bytes */ For the records, this is also widely used: $git grep static.*regmap_config | wc -l 1327 Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e039cd8fe415dd7ab3169948c08a5311db9fb9a.1715024007.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-06 21:33:33 +02:00
regmap: Add "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: mmio: Introduce IO accessors that can talk to IO port Some users may use regmap MMIO for IO ports, and this can be done by assigning ioreadXX()/iowriteXX() and their Big Endian counterparts to the regmap context. Add IO port support with a corresponding flag added. While doing that, make sure that user won't select relaxed MMIO access along with IO port because the latter have no relaxed variants. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/20220808203401.35153-4-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-08 23:33:59 +03:00
regmap: Reorder fields in 'struct regmap_config' to save some memory On x86_64 and allmodconfig, this shrinks the size of 'struct regmap_config' from 328 to 312 bytes. This is usually a win, because this structure is used as a static global variable. When moving the kerneldoc fields, I've tried to keep the layout as consistent as possible, which is not really easy! Before: /* size: 328, cachelines: 6, members: 55 */ /* sum members: 296, holes: 6, sum holes: 25 */ /* padding: 7 */ /* last cacheline: 8 bytes */ After: /* size: 312, cachelines: 5, members: 55 */ /* sum members: 296, holes: 5, sum holes: 16 */ /* last cacheline: 56 bytes */ For the records, this is also widely used: $git grep static.*regmap_config | wc -l 1327 Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e039cd8fe415dd7ab3169948c08a5311db9fb9a.1715024007.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-06 21:33:33 +02:00
regmap: clairify meaning of max_register The exact meaning of max_register is not entierly clear. Follow the common wording and use "address" instead of "index". Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-19 17:14:39 -08: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: 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: Allow drivers to specify register defaults It is useful for the register cache code to be able to specify the default values for the device registers. The major use is when restoring the register cache after suspend, knowing the register defaults allows us to skip registers that are at their default values when we resume which can be a substantial win on larger modern devices. For some devices (mostly older ones) the hardware does not support readback so the only way we can know the values is from code and so initializing the cache with default values makes it much easier for drivers work with read/modify/write updates. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-19 18:09:38 +09: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: 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: 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: 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: 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: Allow empty read/write_flag_mask All zero read and write masks in the regmap config are used to signal no special mask is needed and the bus defaults are used. In some devices all zero read/write masks are the special mask and bus defaults should not be used. To signal this a new variable is added. For example SPI often sets bit 7 in address to signal to the device a read is requested. On TI AFE44xx parts with SPI interfaces no bit needs to be set as registers are either read or write only and the operation can be determined from the address only. For this case both masks must be zero to not effect the address. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-07 17:19:09 -06:00
regmap: mmio: add config option to allow relaxed MMIO accesses On some platforms (eg armv7 due to the CONFIG_ARM_DMA_MEM_BUFFERABLE) MMIO R/W operations always add memory barriers which can increase load, decrease battery life or in general reduce performance unnecessarily on devices which access a lot of configuration registers and where ordering does not matter (eg. media accelerators like the Verisilicon / Hantro video decoders). Drivers used to call the relaxed MMIO variants directly but since they are now accessing the MMIO registers via regmaps (to compensate for different VPU HW reg layouts via regmap fields), there is a need for a relaxed API / config to preserve existing behaviour. Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Link: https://lore.kernel.org/r/20201014203024.954369-1-adrian.ratiu@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-14 23:30:24 +03:00
regmap: split up regmap_config.use_single_rw Split regmap_config.use_single_rw into use_single_read and use_single_write. This change enables drivers of devices which only support bulk operations in one direction to use the regmap_bulk_*() functions for both directions and have their bulk operation split into single operations only when necessary. Update all struct regmap_config instances where use_single_rw==true to instead set both use_single_read and use_single_write. No attempt was made to evaluate whether it is possible to set only one of use_single_read or use_single_write. Signed-off-by: David Frey <dpfrey@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-01 09:50:41 -07: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: 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: Add one flag to indicate if a hwlock should be used Since the hwlock id 0 is valid for hardware spinlock core, but now id 0 is treated as one invalid value for regmap. Thus we should add one extra flag for regmap config to indicate if a hardware spinlock should be used, then id 0 can be valid for regmap to request. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-12-25 14:37:09 +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: 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: Reorder fields in 'struct regmap_config' to save some memory On x86_64 and allmodconfig, this shrinks the size of 'struct regmap_config' from 328 to 312 bytes. This is usually a win, because this structure is used as a static global variable. When moving the kerneldoc fields, I've tried to keep the layout as consistent as possible, which is not really easy! Before: /* size: 328, cachelines: 6, members: 55 */ /* sum members: 296, holes: 6, sum holes: 25 */ /* padding: 7 */ /* last cacheline: 8 bytes */ After: /* size: 312, cachelines: 5, members: 55 */ /* sum members: 296, holes: 5, sum holes: 16 */ /* last cacheline: 56 bytes */ For the records, this is also widely used: $git grep static.*regmap_config | wc -l 1327 Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e039cd8fe415dd7ab3169948c08a5311db9fb9a.1715024007.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-06 21:33:33 +02:00
regmap: Add kerneldoc for struct regmap_config Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:28:58 +01:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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: 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: 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: 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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Allow devices to specify which registers are accessible This is currently unused but we need to know which registers exist and their properties in order to implement diagnostics like register map dumps and the cache features. We use callbacks partly because properties can vary at runtime (eg, through access locks on registers) and partly because big switch statements are a good compromise between readable code and small data size for providing information on big register maps. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-07-20 22:33:39 +01:00
regmap: Add precious registers to the driver interface Some devices are sensitive to reads on their registers, especially for things like clear on read interrupt status registers. Avoid creating problems with these with things like debugfs by allowing drivers to tell the core about them. If a register is marked as precious then the core will not internally generate any reads of it. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-08 15:40:22 +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: allow to disable all locking mechanisms We have a use case in the at24 EEPROM driver (recently converted to using regmap instead of raw i2c/smbus calls) where we read from/write to the regmap in a loop, while protecting the entire loop with a mutex. Currently this implicitly makes us use two mutexes - one in the driver and one in regmap. While browsing the code for similar use cases I noticed a significant number of places where locking *seems* redundant. Allow users to completely disable any locking mechanisms in regmap config. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-12-06 15:26:21 +01:00
regmap: Add "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: allow to define reg_update_bits for no bus configuration Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a dedicated function in regmap_config for reg_update_bits in no bus configuration. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-04 16:00:40 +01: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 "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: Reorder fields in 'struct regmap_config' to save some memory On x86_64 and allmodconfig, this shrinks the size of 'struct regmap_config' from 328 to 312 bytes. This is usually a win, because this structure is used as a static global variable. When moving the kerneldoc fields, I've tried to keep the layout as consistent as possible, which is not really easy! Before: /* size: 328, cachelines: 6, members: 55 */ /* sum members: 296, holes: 6, sum holes: 25 */ /* padding: 7 */ /* last cacheline: 8 bytes */ After: /* size: 312, cachelines: 5, members: 55 */ /* sum members: 296, holes: 5, sum holes: 16 */ /* last cacheline: 56 bytes */ For the records, this is also widely used: $git grep static.*regmap_config | wc -l 1327 Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e039cd8fe415dd7ab3169948c08a5311db9fb9a.1715024007.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-06 21:33:33 +02:00
regmap: Add "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: mmio: Introduce IO accessors that can talk to IO port Some users may use regmap MMIO for IO ports, and this can be done by assigning ioreadXX()/iowriteXX() and their Big Endian counterparts to the regmap context. Add IO port support with a corresponding flag added. While doing that, make sure that user won't select relaxed MMIO access along with IO port because the latter have no relaxed variants. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/20220808203401.35153-4-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-08 23:33:59 +03:00
regmap: Add "no-bus" option for regmap API This commit adds provision for "no-bus" usage of the regmap API. In this configuration user can provide API with two callbacks 'reg_read' and 'reg_write' which are to be called when reads and writes to one of device's registers is performed. This is useful for devices that expose registers but whose register access sequence does not fit the 'bus' abstraction. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-01-27 10:49:05 -08:00
regmap: Reorder fields in 'struct regmap_config' to save some memory On x86_64 and allmodconfig, this shrinks the size of 'struct regmap_config' from 328 to 312 bytes. This is usually a win, because this structure is used as a static global variable. When moving the kerneldoc fields, I've tried to keep the layout as consistent as possible, which is not really easy! Before: /* size: 328, cachelines: 6, members: 55 */ /* sum members: 296, holes: 6, sum holes: 25 */ /* padding: 7 */ /* last cacheline: 8 bytes */ After: /* size: 312, cachelines: 5, members: 55 */ /* sum members: 296, holes: 5, sum holes: 16 */ /* last cacheline: 56 bytes */ For the records, this is also widely used: $git grep static.*regmap_config | wc -l 1327 Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e039cd8fe415dd7ab3169948c08a5311db9fb9a.1715024007.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-06 21:33:33 +02:00
regmap: Allow drivers to specify register defaults It is useful for the register cache code to be able to specify the default values for the device registers. The major use is when restoring the register cache after suspend, knowing the register defaults allows us to skip registers that are at their default values when we resume which can be a substantial win on larger modern devices. For some devices (mostly older ones) the hardware does not support readback so the only way we can know the values is from code and so initializing the cache with default values makes it much easier for drivers work with read/modify/write updates. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-08-19 18:09:38 +09: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: 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: Make reg_config reg_defaults const The reg_defaults field usually points to a static per driver array, which should not be modified. Make requirement this explicit by making reg_defaults const. To allow this the regcache_init code needs some minor changes. Previoulsy the reg_config was not available in regcache_init and regmap->reg_defaults was used to pass the default register set to regcache_init. Now that the reg_config is available we can work on it directly. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-11-16 16:28:17 +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: 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: 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: Allow empty read/write_flag_mask All zero read and write masks in the regmap config are used to signal no special mask is needed and the bus defaults are used. In some devices all zero read/write masks are the special mask and bus defaults should not be used. To signal this a new variable is added. For example SPI often sets bit 7 in address to signal to the device a read is requested. On TI AFE44xx parts with SPI interfaces no bit needs to be set as registers are either read or write only and the operation can be determined from the address only. For this case both masks must be zero to not effect the address. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-07 17:19:09 -06: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: split up regmap_config.use_single_rw Split regmap_config.use_single_rw into use_single_read and use_single_write. This change enables drivers of devices which only support bulk operations in one direction to use the regmap_bulk_*() functions for both directions and have their bulk operation split into single operations only when necessary. Update all struct regmap_config instances where use_single_rw==true to instead set both use_single_read and use_single_write. No attempt was made to evaluate whether it is possible to set only one of use_single_read or use_single_write. Signed-off-by: David Frey <dpfrey@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-01 09:50:41 -07:00
regmap: mmio: add config option to allow relaxed MMIO accesses On some platforms (eg armv7 due to the CONFIG_ARM_DMA_MEM_BUFFERABLE) MMIO R/W operations always add memory barriers which can increase load, decrease battery life or in general reduce performance unnecessarily on devices which access a lot of configuration registers and where ordering does not matter (eg. media accelerators like the Verisilicon / Hantro video decoders). Drivers used to call the relaxed MMIO variants directly but since they are now accessing the MMIO registers via regmaps (to compensate for different VPU HW reg layouts via regmap fields), there is a need for a relaxed API / config to preserve existing behaviour. Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Link: https://lore.kernel.org/r/20201014203024.954369-1-adrian.ratiu@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-14 23:30:24 +03: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: allow busses to request formatting with specific endianness Add a field to struct regmap_bus that allows bus drivers to request that register addresses and values be formatted with a specific endianness. The default endianness is unchanged from current operation: Big. Implement native endian formatting/parsing for 16- and 32-bit values. This will be enough to support regmap-mmio.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-24 10:47:26 -06:00
regmap: Add one flag to indicate if a hwlock should be used Since the hwlock id 0 is valid for hardware spinlock core, but now id 0 is treated as one invalid value for regmap. Thus we should add one extra flag for regmap config to indicate if a hardware spinlock should be used, then id 0 can be valid for regmap to request. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-12-25 14:37:09 +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: 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: Add can_sleep configuration option Regmap can't sleep if spinlock is used for the locking protection. This patch fixes regression caused by a previous commit that switched regmap to use fsleep() and this broke Amlogic S922X platform. This patch adds new configuration option for regmap users, allowing to specify whether regmap operations can sleep and assuming that sleep is allowed if mutex is used for the regmap locking protection. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 2b32d2f7ce0a ("regmap: Use flexible sleep") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200902141843.6591-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-02 17:18:43 +03:00
regmap: Reorder fields in 'struct regmap_config' to save some memory On x86_64 and allmodconfig, this shrinks the size of 'struct regmap_config' from 328 to 312 bytes. This is usually a win, because this structure is used as a static global variable. When moving the kerneldoc fields, I've tried to keep the layout as consistent as possible, which is not really easy! Before: /* size: 328, cachelines: 6, members: 55 */ /* sum members: 296, holes: 6, sum holes: 25 */ /* padding: 7 */ /* last cacheline: 8 bytes */ After: /* size: 312, cachelines: 5, members: 55 */ /* sum members: 296, holes: 5, sum holes: 16 */ /* last cacheline: 56 bytes */ For the records, this is also widely used: $git grep static.*regmap_config | wc -l 1327 Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e039cd8fe415dd7ab3169948c08a5311db9fb9a.1715024007.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-06 21:33:33 +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: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +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: 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: 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: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: wrong descriptions in regmap_range_cfg Swap selector_mask and selector_shift descriptions Signed-off-by: Phong LE <ple@baylibre.com> Link: https://lore.kernel.org/r/20200219140906.29180-1-ple@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-19 15:09:06 +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: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +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: 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: 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 generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +00:00
regmap: sdw-mbq: Add support for SDCA deferred controls The SDCA specification allows for controls to be deferred. In the case of a deferred control the device will return COMMAND_IGNORED to the 8-bit operation that would cause the value to commit. Which is the final 8-bits on a write, or the first 8-bits on a read. In the case of receiving a defer, the regmap will poll the SDCA function busy bit, after which the transaction will be retried, returning an error if the function busy does not clear within a chip specific timeout. Since this is common SDCA functionality which is the 99% use-case for MBQs it makes sense to incorporate this functionality into the register map. If no MBQ configuration is specified, the behaviour will default to the existing behaviour. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:06 +00:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +00:00
regmap: sdw-mbq: Add support for SDCA deferred controls The SDCA specification allows for controls to be deferred. In the case of a deferred control the device will return COMMAND_IGNORED to the 8-bit operation that would cause the value to commit. Which is the final 8-bits on a write, or the first 8-bits on a read. In the case of receiving a defer, the regmap will poll the SDCA function busy bit, after which the transaction will be retried, returning an error if the function busy does not clear within a chip specific timeout. Since this is common SDCA functionality which is the 99% use-case for MBQs it makes sense to incorporate this functionality into the register map. If no MBQ configuration is specified, the behaviour will default to the existing behaviour. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:06 +00:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +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: 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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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: 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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: add reg_read/reg_write callbacks to regmap_bus struct Some busses do not support sending/receiving multiple registers in one go. Such kind of busses just unpack the registers that have been previously packed by the regmap core or pack registers that will be later unpacked by the core code. Add reg_write and reg_read callbacks in order to optimize access through this kind of busses. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-04-17 11:40:11 +02:00
regmap: Support accelerated noinc operations Several architectures have accelerated operations for MMIO operations writing to a single register, such as writesb, writesw, writesl, writesq, readsb, readsw, readsl and readsq but regmap currently cannot use them because we have no hooks for providing an accelerated noinc back-end for MMIO. Solve this by providing reg_[read/write]_noinc callbacks for the bus abstraction, so that the regmap-mmio bus can use this. Currently I do not see a need to support this for custom regmaps so it is only added to the bus. Callbacks are passed a void * with the array of values and a count which is the number of items of the byte chunk size for the specific register width. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220816204832.265837-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-16 22:48:31 +02:00
regmap: add reg_read/reg_write callbacks to regmap_bus struct Some busses do not support sending/receiving multiple registers in one go. Such kind of busses just unpack the registers that have been previously packed by the regmap core or pack registers that will be later unpacked by the core code. Add reg_write and reg_read callbacks in order to optimize access through this kind of busses. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-04-17 11:40:11 +02:00
regmap: Support accelerated noinc operations Several architectures have accelerated operations for MMIO operations writing to a single register, such as writesb, writesw, writesl, writesq, readsb, readsw, readsl and readsq but regmap currently cannot use them because we have no hooks for providing an accelerated noinc back-end for MMIO. Solve this by providing reg_[read/write]_noinc callbacks for the bus abstraction, so that the regmap-mmio bus can use this. Currently I do not see a need to support this for custom regmaps so it is only added to the bus. Callbacks are passed a void * with the array of values and a count which is the number of items of the byte chunk size for the specific register width. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220816204832.265837-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-16 22:48:31 +02: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 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: 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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +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: Reorder fields in 'struct regmap_bus' to save some memory Group some bool variables to reduce hole and avoid padding. On x86_64, this shrinks the size from 136 to 128 bytes. As an example: $ size drivers/base/regmap/regmap-fsi.o (Before) text data bss dec hex filename 4837 136 0 4973 136d drivers/base/regmap/regmap-fsi.o $ size drivers/base/regmap/regmap-fsi.o (After) text data bss dec hex filename 4701 136 0 4837 12e5 drivers/base/regmap/regmap-fsi.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/077ca39622c8870a3ea932298a9cec34f7a8295a.1676363976.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-14 09:40:14 +01:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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: Add missing comments about struct regmap_bus There are some fields of this struct undocumented or old. This patch updates the missing comments. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-21 10:26:40 +02:00
regmap: Support accelerated noinc operations Several architectures have accelerated operations for MMIO operations writing to a single register, such as writesb, writesw, writesl, writesq, readsb, readsw, readsl and readsq but regmap currently cannot use them because we have no hooks for providing an accelerated noinc back-end for MMIO. Solve this by providing reg_[read/write]_noinc callbacks for the bus abstraction, so that the regmap-mmio bus can use this. Currently I do not see a need to support this for custom regmaps so it is only added to the bus. Callbacks are passed a void * with the array of values and a count which is the number of items of the byte chunk size for the specific register width. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220816204832.265837-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-16 22:48:31 +02:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Add missing comments about struct regmap_bus There are some fields of this struct undocumented or old. This patch updates the missing comments. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-21 10:26:40 +02: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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: allow busses to request formatting with specific endianness Add a field to struct regmap_bus that allows bus drivers to request that register addresses and values be formatted with a specific endianness. The default endianness is unchanged from current operation: Big. Implement native endian formatting/parsing for 16- and 32-bit values. This will be enough to support regmap-mmio.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-24 10:47:26 -06: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 generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +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: Reorder fields in 'struct regmap_bus' to save some memory Group some bool variables to reduce hole and avoid padding. On x86_64, this shrinks the size from 136 to 128 bytes. As an example: $ size drivers/base/regmap/regmap-fsi.o (Before) text data bss dec hex filename 4837 136 0 4973 136d drivers/base/regmap/regmap-fsi.o $ size drivers/base/regmap/regmap-fsi.o (After) text data bss dec hex filename 4701 136 0 4837 12e5 drivers/base/regmap/regmap-fsi.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/077ca39622c8870a3ea932298a9cec34f7a8295a.1676363976.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-14 09:40:14 +01:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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: add reg_read/reg_write callbacks to regmap_bus struct Some busses do not support sending/receiving multiple registers in one go. Such kind of busses just unpack the registers that have been previously packed by the regmap core or pack registers that will be later unpacked by the core code. Add reg_write and reg_read callbacks in order to optimize access through this kind of busses. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-04-17 11:40:11 +02:00
regmap: Support accelerated noinc operations Several architectures have accelerated operations for MMIO operations writing to a single register, such as writesb, writesw, writesl, writesq, readsb, readsw, readsl and readsq but regmap currently cannot use them because we have no hooks for providing an accelerated noinc back-end for MMIO. Solve this by providing reg_[read/write]_noinc callbacks for the bus abstraction, so that the regmap-mmio bus can use this. Currently I do not see a need to support this for custom regmaps so it is only added to the bus. Callbacks are passed a void * with the array of values and a count which is the number of items of the byte chunk size for the specific register width. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220816204832.265837-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-16 22:48:31 +02: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 generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: add reg_read/reg_write callbacks to regmap_bus struct Some busses do not support sending/receiving multiple registers in one go. Such kind of busses just unpack the registers that have been previously packed by the regmap core or pack registers that will be later unpacked by the core code. Add reg_write and reg_read callbacks in order to optimize access through this kind of busses. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-04-17 11:40:11 +02:00
regmap: Support accelerated noinc operations Several architectures have accelerated operations for MMIO operations writing to a single register, such as writesb, writesw, writesl, writesq, readsb, readsw, readsl and readsq but regmap currently cannot use them because we have no hooks for providing an accelerated noinc back-end for MMIO. Solve this by providing reg_[read/write]_noinc callbacks for the bus abstraction, so that the regmap-mmio bus can use this. Currently I do not see a need to support this for custom regmaps so it is only added to the bus. Callbacks are passed a void * with the array of values and a count which is the number of items of the byte chunk size for the specific register width. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220816204832.265837-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-16 22:48:31 +02: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: 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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: allow busses to request formatting with specific endianness Add a field to struct regmap_bus that allows bus drivers to request that register addresses and values be formatted with a specific endianness. The default endianness is unchanged from current operation: Big. Implement native endian formatting/parsing for 16- and 32-bit values. This will be enough to support regmap-mmio.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-24 10:47:26 -06: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 generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add MDIO bus support Basic support for MDIO bus access. Support only includes clause-22 register access, with 5-bit addresses, and 16-bit wide registers. Signed-off-by: Sander Vanheule <sander@svanheule.net> Link: https://lore.kernel.org/r/63b99a2fec2c4ea3c461d59d451af8d675ecf312.1621279162.git.sander@svanheule.net Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-17 21:28:03 +02:00
regmap: add SCCB support This adds Serial Camera Control Bus (SCCB) support for regmap API that is intended to be used by some of Omnivision sensor drivers. The ov772x and ov9650 drivers are going to use this SCCB regmap API. The ov772x driver was previously only worked with the i2c controller drivers that support I2C_FUNC_PROTOCOL_MANGLING, because the ov772x device doesn't support repeated starts. After commit 0b964d183cbf ("media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING"), reading ov772x register is replaced with issuing two separated i2c messages in order to avoid repeated start. Using this SCCB regmap hides the implementation detail. The ov9650 driver also issues two separated i2c messages to read the registers as the device doesn't support repeated start. So it can make use of this SCCB regmap. Cc: Mark Brown <broonie@kernel.org> Cc: Peter Rosin <peda@axentia.se> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-17 00:47:48 +09:00
regmap: add SLIMbus support This patch adds support to read/write SLIMbus value elements. Currently it only supports byte read/write. Adding this support in regmap would give codec drivers more flexibility when there are more than 2 control interfaces like SLIMbus, i2c. Without this patch each codec driver has to directly call SLIMbus value element apis, and this could would get messy once we want to add i2c interface to it. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviwed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-11 23:43:02 +00:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add 1-Wire bus support Add basic support regmap (register map access) API for 1-Wire bus Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-02 10:06:27 +03:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add SoundWire bus support SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-08 15:50:59 +05:30
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +00:00
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: add Intel SPI Slave to AVMM Bus Bridge support This patch add support for regmap APIs that are intended to be used by the drivers of some SPI slave chips which integrate the "SPI slave to Avalon Master Bridge" (spi-avmm) IP. The spi-avmm IP acts as a bridge to convert encoded streams of bytes from the host to the chip's internal register read/write on Avalon bus. The driver implements the register read/write operations for a generic SPI master to access the sub devices behind spi-avmm bridge. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Reviewed-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Link: https://lore.kernel.org/r/1597822497-25107-2-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-19 15:34:56 +08:00
regmap: Add FSI bus support Add regmap support for the FSI bus. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20221102205148.1334459-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-02 15:51:44 -05:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add MDIO bus support Basic support for MDIO bus access. Support only includes clause-22 register access, with 5-bit addresses, and 16-bit wide registers. Signed-off-by: Sander Vanheule <sander@svanheule.net> Link: https://lore.kernel.org/r/63b99a2fec2c4ea3c461d59d451af8d675ecf312.1621279162.git.sander@svanheule.net Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-17 21:28:03 +02:00
regmap: add SCCB support This adds Serial Camera Control Bus (SCCB) support for regmap API that is intended to be used by some of Omnivision sensor drivers. The ov772x and ov9650 drivers are going to use this SCCB regmap API. The ov772x driver was previously only worked with the i2c controller drivers that support I2C_FUNC_PROTOCOL_MANGLING, because the ov772x device doesn't support repeated starts. After commit 0b964d183cbf ("media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING"), reading ov772x register is replaced with issuing two separated i2c messages in order to avoid repeated start. Using this SCCB regmap hides the implementation detail. The ov9650 driver also issues two separated i2c messages to read the registers as the device doesn't support repeated start. So it can make use of this SCCB regmap. Cc: Mark Brown <broonie@kernel.org> Cc: Peter Rosin <peda@axentia.se> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-17 00:47:48 +09:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add 1-Wire bus support Add basic support regmap (register map access) API for 1-Wire bus Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-02 10:06:27 +03:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add SoundWire bus support SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-08 15:50:59 +05:30
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +00:00
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: add missing prototype for devm_init_slimbus For some reason the devm variant of slimbus init is not added into the header eventhough this __devm_regmap_init_slimbus() is an exported function. This patch adds this. This also fixes below warning in regmap-slimbus.c regmap-slimbus.c:65:15: warning: symbol '__devm_regmap_init_slimbus' was not declared. Should it be static? regmap-slimbus.c:65:16: warning: no previous prototype for '__devm_regmap_init_slimbus' [-Wmissing-prototypes] Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-25 14:50:36 +01:00
regmap: add i3c bus support Add basic support for i3c bus. This is a simple implementation that only give support for SDR Read and Write commands. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06 17:12:02 +02:00
regmap: add Intel SPI Slave to AVMM Bus Bridge support This patch add support for regmap APIs that are intended to be used by the drivers of some SPI slave chips which integrate the "SPI slave to Avalon Master Bridge" (spi-avmm) IP. The spi-avmm IP acts as a bridge to convert encoded streams of bytes from the host to the chip's internal register read/write on Avalon bus. The driver implements the register read/write operations for a generic SPI master to access the sub devices behind spi-avmm bridge. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Reviewed-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Link: https://lore.kernel.org/r/1597822497-25107-2-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-19 15:34:56 +08:00
regmap: Add FSI bus support Add regmap support for the FSI bus. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20221102205148.1334459-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-02 15:51:44 -05:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Separate regmap dev initialization Create special function regmap_attach_dev which can be called separately out of regmap_init. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-02-10 16:22:33 +01:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Add SPI bus support Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-12 11:42:10 +02:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: ac97: Add generic AC'97 callbacks Use the recently added support for bus operations to provide a standard mapping for AC'97 register I/O. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2014-11-18 19:45:51 +01:00
regmap: Add MDIO bus support Basic support for MDIO bus access. Support only includes clause-22 register access, with 5-bit addresses, and 16-bit wide registers. Signed-off-by: Sander Vanheule <sander@svanheule.net> Link: https://lore.kernel.org/r/63b99a2fec2c4ea3c461d59d451af8d675ecf312.1621279162.git.sander@svanheule.net Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-17 21:28:03 +02:00
regmap: add SCCB support This adds Serial Camera Control Bus (SCCB) support for regmap API that is intended to be used by some of Omnivision sensor drivers. The ov772x and ov9650 drivers are going to use this SCCB regmap API. The ov772x driver was previously only worked with the i2c controller drivers that support I2C_FUNC_PROTOCOL_MANGLING, because the ov772x device doesn't support repeated starts. After commit 0b964d183cbf ("media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING"), reading ov772x register is replaced with issuing two separated i2c messages in order to avoid repeated start. Using this SCCB regmap hides the implementation detail. The ov9650 driver also issues two separated i2c messages to read the registers as the device doesn't support repeated start. So it can make use of this SCCB regmap. Cc: Mark Brown <broonie@kernel.org> Cc: Peter Rosin <peda@axentia.se> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-17 00:47:48 +09:00
regmap: add SLIMbus support This patch adds support to read/write SLIMbus value elements. Currently it only supports byte read/write. Adding this support in regmap would give codec drivers more flexibility when there are more than 2 control interfaces like SLIMbus, i2c. Without this patch each codec driver has to directly call SLIMbus value element apis, and this could would get messy once we want to add i2c interface to it. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviwed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-11 23:43:02 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Add 1-Wire bus support Add basic support regmap (register map access) API for 1-Wire bus Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-02 10:06:27 +03:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Annotate that MMIO implies fast IO Document that using the MMIO helpers will automatically enable the 'fast_io' parameter. This makes the used locking scheme more transparent and avoids superfluous setting of this parameter in drivers. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20250725110337.4303-2-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-25 13:03:27 +02:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Annotate that MMIO implies fast IO Document that using the MMIO helpers will automatically enable the 'fast_io' parameter. This makes the used locking scheme more transparent and avoids superfluous setting of this parameter in drivers. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20250725110337.4303-2-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-25 13:03:27 +02:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Add SoundWire bus support SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-08 15:50:59 +05:30
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +00:00
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: add Intel SPI Slave to AVMM Bus Bridge support This patch add support for regmap APIs that are intended to be used by the drivers of some SPI slave chips which integrate the "SPI slave to Avalon Master Bridge" (spi-avmm) IP. The spi-avmm IP acts as a bridge to convert encoded streams of bytes from the host to the chip's internal register read/write on Avalon bus. The driver implements the register read/write operations for a generic SPI master to access the sub devices behind spi-avmm bridge. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Reviewed-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Link: https://lore.kernel.org/r/1597822497-25107-2-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-19 15:34:56 +08:00
regmap: Add SoundWire bus support SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-08 15:50:59 +05:30
regmap: Add FSI bus support Add regmap support for the FSI bus. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20221102205148.1334459-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-02 15:51:44 -05:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Add MDIO bus support Basic support for MDIO bus access. Support only includes clause-22 register access, with 5-bit addresses, and 16-bit wide registers. Signed-off-by: Sander Vanheule <sander@svanheule.net> Link: https://lore.kernel.org/r/63b99a2fec2c4ea3c461d59d451af8d675ecf312.1621279162.git.sander@svanheule.net Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-17 21:28:03 +02:00
regmap: add SCCB support This adds Serial Camera Control Bus (SCCB) support for regmap API that is intended to be used by some of Omnivision sensor drivers. The ov772x and ov9650 drivers are going to use this SCCB regmap API. The ov772x driver was previously only worked with the i2c controller drivers that support I2C_FUNC_PROTOCOL_MANGLING, because the ov772x device doesn't support repeated starts. After commit 0b964d183cbf ("media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING"), reading ov772x register is replaced with issuing two separated i2c messages in order to avoid repeated start. Using this SCCB regmap hides the implementation detail. The ov9650 driver also issues two separated i2c messages to read the registers as the device doesn't support repeated start. So it can make use of this SCCB regmap. Cc: Mark Brown <broonie@kernel.org> Cc: Peter Rosin <peda@axentia.se> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-17 00:47:48 +09:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Add 1-Wire bus support Add basic support regmap (register map access) API for 1-Wire bus Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-02 10:06:27 +03:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Annotate that MMIO implies fast IO Document that using the MMIO helpers will automatically enable the 'fast_io' parameter. This makes the used locking scheme more transparent and avoids superfluous setting of this parameter in drivers. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20250725110337.4303-2-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-25 13:03:27 +02:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Annotate that MMIO implies fast IO Document that using the MMIO helpers will automatically enable the 'fast_io' parameter. This makes the used locking scheme more transparent and avoids superfluous setting of this parameter in drivers. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20250725110337.4303-2-wsa+renesas@sang-engineering.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-25 13:03:27 +02:00
regmap: mmio: add register clock support Some mmio devices have a dedicated interface clock that needs to be enabled to access their registers. This patch optionally enables a clock before accessing registers in the regmap_bus callbacks. I added (devm_)regmap_init_mmio_clk variants of the init functions that have an added clk_id string parameter. This is passed to clk_get to request the clock from the clk framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-02-14 17:39:08 +01:00
regmap: Use different lockdep class for each regmap init call Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-08 14:30:18 +08:00
regmap: Implement managed regmap_init() Save error handling and unwinding code in drivers by providing managed versions of the regmap init functions, simplifying usage. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-30 19:56:52 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Move documentation to regmap.h Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-11 18:04:21 +08:00
regmap: Implement managed regmap_init() Save error handling and unwinding code in drivers by providing managed versions of the regmap init functions, simplifying usage. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-30 19:56:52 +00:00
regmap: Add SoundWire bus support SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-08 15:50:59 +05:30
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: sdw-mbq: Add support for further MBQ register sizes SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07 15:44:05 +00:00
regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-04 01:22:23 +08:00
regmap: add missing prototype for devm_init_slimbus For some reason the devm variant of slimbus init is not added into the header eventhough this __devm_regmap_init_slimbus() is an exported function. This patch adds this. This also fixes below warning in regmap-slimbus.c regmap-slimbus.c:65:15: warning: symbol '__devm_regmap_init_slimbus' was not declared. Should it be static? regmap-slimbus.c:65:16: warning: no previous prototype for '__devm_regmap_init_slimbus' [-Wmissing-prototypes] Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-25 14:50:36 +01:00
regmap: add i3c bus support Add basic support for i3c bus. This is a simple implementation that only give support for SDR Read and Write commands. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06 17:12:02 +02:00
regmap: add Intel SPI Slave to AVMM Bus Bridge support This patch add support for regmap APIs that are intended to be used by the drivers of some SPI slave chips which integrate the "SPI slave to Avalon Master Bridge" (spi-avmm) IP. The spi-avmm IP acts as a bridge to convert encoded streams of bytes from the host to the chip's internal register read/write on Avalon bus. The driver implements the register read/write operations for a generic SPI master to access the sub devices behind spi-avmm bridge. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Reviewed-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Link: https://lore.kernel.org/r/1597822497-25107-2-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-19 15:34:56 +08:00
regmap: Add FSI bus support Add regmap support for the FSI bus. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20221102205148.1334459-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-02 15:51:44 -05:00
regmap: mmio: Add function to attach a clock regmap_init_mmio_clk allows to specify a clock that needs to be enabled while accessing the registers. However, that clock is retrieved through its clock ID, which means it will lookup that clock based on the current device that registers the regmap, and, in the DT case, will only look in that device OF node. This might be problematic if the clock to enable is stored in another node. Let's add a function that allows to attach a clock that has already been retrieved to a regmap in order to fix this. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-21 10:20:25 +01:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Allow drivers to reinitialise the register cache at runtime Sometimes the register map information may change in ways that drivers can discover at runtime. For example, new revisions of a device may add new registers. Support runtime discovery by drivers by allowing the register cache to be reinitialised with a new function regmap_reinit_cache() which discards the existing cache and creates a new one. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-12-03 17:06:20 +00: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: Add regmap_get_device Add a new function regmap_get_device to obtain the underlying struct device from a regmap. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-21 18:38:47 +03:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Provide asynchronous write and update bits operations Make it easier for drivers to include single register writes in asynchronous sequences by providing async versions of the write and update bits operations. The update bits operations are only likely to be effective when used with devices that have caches but this is common enough to be useful. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-09 13:30:10 +01:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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_bulk_write() for register write The bulk_write() supports the data transfer to multi register which takes the data into cpu_endianness format and does formatting of data to device format before sending to device. The transfer can be completed in single transfer or multiple transfer based on data formatting. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-12 19:49:43 +05:30
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
regmap: new API regmap_multi_reg_write() definition New API regmap_multi_reg_write() is defined that allows a set of reg,val pairs to be written to a I2C client device as one block transfer from the point of view of a single I2C master system. A simple demonstration implementation is included that just splits the block write request into a sequence of single register writes. The implementation will be modified later to support those I2C clients that implement the alternative non-standard MULTIWRITE block write mode so to achieve a single I2C transfer that will be atomic even in multiple I2C master systems. Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com> Signed-off-by: David Dajun Chen <david.chen@diasemi.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-11 15:31:11 +01:00
regmap: Add bypassed version of regmap_multi_reg_write Devices with more complex boot proceedures may occasionally apply the register patch manual. regmap_multi_reg_write is a logical way to do so, however the patch must be applied with cache bypass on, such that it doesn't override any user settings. This patch adds a regmap_multi_reg_write_bypassed function that applies a set of writes with the bypass enabled. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-02-25 13:45:50 +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
regmap: Add bypassed version of regmap_multi_reg_write Devices with more complex boot proceedures may occasionally apply the register patch manual. regmap_multi_reg_write is a logical way to do so, however the patch must be applied with cache bypass on, such that it doesn't override any user settings. This patch adds a regmap_multi_reg_write_bypassed function that applies a set of writes with the bypass enabled. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-02-25 13:45:50 +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: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: Add regmap_read_bypassed() Add a regmap_read_bypassed() to allow reads from the hardware registers while the regmap is in cache-only mode. A typical use for this is to keep the cache in cache-only mode until the hardware has reached a valid state, but one or more status registers must be polled to determine when this state is reached. For example, firmware download on the cs35l56 can take several seconds if there are multiple amps sharing limited bus bandwidth. This is too long to block in probe() so it is done as a background task. The device must be soft-reset to reboot the firmware and during this time the registers are not accessible, so the cache should be in cache-only. But the driver must poll a register to detect when reboot has completed. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 8a731fd37f8b ("ASoC: cs35l56: Move utility functions to shared file") Link: https://msgid.link/r/20240408101803.43183-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-08 11:18:00 +01:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02: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 generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regmap: regmap_multi_reg_read(): make register list const Mark the list of registers passed into regmap_multi_reg_read() as a pointer to const. This allows the caller to define the register list as const data. This requires making the same change to _regmap_bulk_read(), which is called by regmap_multi_reg_read(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20241211133558.884669-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-12-11 13:35:58 +00:00
regmap: Implement regmap_multi_reg_read() regmap_multi_reg_read() is similar to regmap_bilk_read() but reads from an array of non-sequential registers. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240710015622.1960522-2-linux@roeck-us.net Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-09 18:56:20 -07:00
regmap: add regmap_update_bits_base() Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch adds new regmap_update_bits_base() which is feature merged function. Above functions can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15 05:22:18 +00:00
regmap: convert all regmap_update_bits() and co. macros to static inlines There's no reason to have these as macros. Let's convert them all to static inlines for better readability and stronger typing. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200615072313.11106-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15 09:23:13 +02:00
regmap: Allow users to query the size of register values Generic infrastructure based on top of regmap may want to operate on blocks of data and therefore find it useful to find the size of the register values. Provide an accessor operation for this. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:20:14 -08:00
regmap: Introduce regmap_get_max_register This patch introduces regmap_get_max_register() function which would be used by the infrastructures like nvmem framework built on top of regmap. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-21 17:42:43 +01:00
regmap: Introduce regmap_get_reg_stride This patch introduces regmap_get_reg_stride() function which would be used by the infrastructures like nvmem framework built on top of regmap. Mostly this function would be used for sanity checks on inputs within such infrastructure. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-21 17:42:54 +01:00
regmap: add regmap_might_sleep() With the dawn of MMIO gpio-regmap users, it is desirable to let gpio-regmap ask the regmap if it might sleep during an access so it can pass that information to gpiochip. Add a new regmap_might_sleep() to query the regmap. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20221121150843.1562603-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-21 16:08:42 +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: core: Provide regmap_can_raw_write() operation Mainly useful internally but exported since this is a public API that's being checked for. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-03-26 21:24:20 +00:00
regmap: regmap max_raw_read/write getter functions Add functions to access the maximum size we can read/write using regmap_raw_read/write(). This helps drivers that need to know how much they can write with the raw functions without problems. There are some devices (e.g. bmc150) that have fifos as registers which need to be read in specific chunks otherwise samples are dropped. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-30 09:33:54 +02:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00
regcache: Add support for sorting defaults arrays The defaults array in regcache must be sorted into ascending register address order, because binary search is used to locate values in the array. Add a helper to sort the register defaults array which can be useful for systems that dynamically create a defaults array based on external information. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-17 14:01:56 +00:00
regmap: Prototype regcache_sync() Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 18:21:49 +01:00
regmap: Allow drivers to sync only part of the register cache Provide a regcache_sync_region() operation which allows drivers to write only part of the cache back to the hardware. This is intended for use in cases like power domains or DSP memories where part of the device register map may be reset without fully resetting the device. Fully supporting these devices is likely to require additional work to make specific regions of the register map cache only while they are in reset, but this is enough for most devices. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-23 20:53:37 +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: Allow drivers to control cache_only flag Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 18:22:14 +01:00
regmap: Implement regcache_cache_bypass helper function Ensure we've got a function so users can enable/disable the cache bypass option. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-29 14:36:27 +01:00
regmap: Track if the register cache is dirty and suppress unneeded syncs Allow drivers to optimise out the register cache sync if they didn't need to do one. If the hardware is desynced from the register cache (by power loss for example) then the driver should call regcache_mark_dirty() to let the core know about this. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-26 10:34:22 +02:00
regmap: Let users check if a register is cached The HDA driver has a use case for checking if a register is cached which it bodges in awkwardly and unclearly. Provide an API which allows it to directly do what it's trying to do. Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230717-regmap-cache-check-v1-1-73ef688afae3@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 21:33:03 +01:00
regmap: Allow drivers to control cache_only flag Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 18:22:14 +01:00
regmap: Make regmap_check_range_table() a public API Allow drivers to use an access table as part of their implementation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-08 13:55:23 +01: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
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: add regmap_parse_val api In some cases, we need regmap's format parse_val function to do be/le translation according to the bus configuration. For example, snd_soc_bytes_put() uses regmap to write/read values, and use cpu_to_be() directly to covert MASK into big endian. This is a defect, and should use regmap's format function to do it according to bus configuration. Signed-off-by: Nenghua Cao <nhcao@marvell.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-02-19 18:44:13 +08: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: 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: provide helpers for simple bit operations In many instances regmap_update_bits() is used for simple bit setting and clearing. In these cases the last argument is redundant and we can hide it with a static inline function. This adds three new helpers for simple bit operations: set_bits, clear_bits and test_bits (the last one defined as a regular function). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200528154503.26304-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-28 17:45:02 +02:00
regmap: provide regmap_assign_bits() Add another bits helper to regmap API: this one sets given bits if value is true and clears them if it's false. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/20241108-assign-bits-v1-1-382790562d99@ideasonboard.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08 16:07:37 +02:00
regmap: provide helpers for simple bit operations In many instances regmap_update_bits() is used for simple bit setting and clearing. In these cases the last argument is redundant and we can hide it with a static inline function. This adds three new helpers for simple bit operations: set_bits, clear_bits and test_bits (the last one defined as a regular function). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200528154503.26304-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-28 17:45:02 +02: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: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00: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: correct the description of structure element in reg_field Fix incorrect description of structure element "msb", which is described as "reg". Signed-off-by: Bintian Wang <bintian.wang@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-01-27 20:50:29 +08: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: 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: add helper for per-port regfield initialization Similar to the standalone regfields, add an initializer for the users who need to set .id_size and .id_offset in order to use the regmap_fields_update_bits_base API. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200527234113.2491988-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-28 02:41:03 +03: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 support to regmap_field_bulk_alloc/free apis Usage of regmap_field_alloc becomes much overhead when number of fields exceed more than 3. QCOM LPASS driver has extensively converted to use regmap_fields. Using new bulk api to allocate fields makes it much more cleaner code to read! Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Link: https://lore.kernel.org/r/20200925164856.10315-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-25 17:48:55 +01:00
regmap: allow const array for {devm_,}regmap_field_bulk_alloc reg_fields The reg_fields array fed to {devm_}regmap_field_bulk_alloc is currently not const, which is not correct on semantics (the functions shouldn't change reg_field contents) and prevents pre-defined const reg_field array to be used. As the implementation of this function doesn't change the content of it, just add const to its prototype. Signed-off-by: Icenowy Zheng <icenowy@sipeed.com> Link: https://lore.kernel.org/r/20210802063741.76301-1-icenowy@sipeed.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-02 14:37:41 +08:00
regmap: add support to regmap_field_bulk_alloc/free apis Usage of regmap_field_alloc becomes much overhead when number of fields exceed more than 3. QCOM LPASS driver has extensively converted to use regmap_fields. Using new bulk api to allocate fields makes it much more cleaner code to read! Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Link: https://lore.kernel.org/r/20200925164856.10315-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-25 17:48:55 +01:00
regmap: allow const array for {devm_,}regmap_field_bulk_alloc reg_fields The reg_fields array fed to {devm_}regmap_field_bulk_alloc is currently not const, which is not correct on semantics (the functions shouldn't change reg_field contents) and prevents pre-defined const reg_field array to be used. As the implementation of this function doesn't change the content of it, just add const to its prototype. Signed-off-by: Icenowy Zheng <icenowy@sipeed.com> Link: https://lore.kernel.org/r/20210802063741.76301-1-icenowy@sipeed.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-02 14:37:41 +08:00
regmap: add support to regmap_field_bulk_alloc/free apis Usage of regmap_field_alloc becomes much overhead when number of fields exceed more than 3. QCOM LPASS driver has extensively converted to use regmap_fields. Using new bulk api to allocate fields makes it much more cleaner code to read! Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Link: https://lore.kernel.org/r/20200925164856.10315-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-25 17:48:55 +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_field_update_bits_base() This patch adds new regmap_field_update_bits_base() which is using regmap_update_bits_base(). Current regmap_field_xxx() can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15 05:23:55 +00: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_fields_update_bits_base() This patch adds new regmap_fields_update_bits_base() which is using regmap_update_bits_base(). Current regmap_fields_xxx() can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15 05:24:51 +00:00
regmap: convert all regmap_update_bits() and co. macros to static inlines There's no reason to have these as macros. Let's convert them all to static inlines for better readability and stronger typing. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200615072313.11106-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15 09:23:13 +02:00
regmap: provide regmap_field helpers for simple bit operations We have set/clear/test operations for regmap, but not for regmap_field yet. So let's introduce regmap_field helpers too. In many instances regmap_field_update_bits() is used for simple bit setting and clearing. In these cases the last argument is redundant and we can hide it with a static inline function. This adds three new helpers for simple bit operations: set_bits, clear_bits and test_bits (the last one defined as a regular function). Signed-off-by: Li Chen <lchen@ambarella.com> Link: https://lore.kernel.org/r/180eef422c3.deae9cd960729.8518395646822099769@zohomail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-22 20:26:58 -07:00
regmap: convert all regmap_update_bits() and co. macros to static inlines There's no reason to have these as macros. Let's convert them all to static inlines for better readability and stronger typing. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200615072313.11106-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15 09:23:13 +02:00
regmap: regmap-irq/gpio-max77620: add level-irq support Add level active IRQ support to regmap-irq irqchip. Change breaks existing regmap-irq type setting. Convert the existing drivers which use regmap-irq with trigger type setting (gpio-max77620) to work with this new approach. So we do not magically support level-active IRQs on gpio-max77620 - but add support to the regmap-irq for chips which support them =) We do not support distinguishing situation where HW supports rising and falling edge detection but not both. Separating this would require inventing yet another flags for IRQ types. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18 13:59:31 +02: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 a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: regmap-irq/gpio-max77620: add level-irq support Add level active IRQ support to regmap-irq irqchip. Change breaks existing regmap-irq type setting. Convert the existing drivers which use regmap-irq with trigger type setting (gpio-max77620) to work with this new approach. So we do not magically support level-active IRQs on gpio-max77620 - but add support to the regmap-irq for chips which support them =) We do not support distinguishing situation where HW supports rising and falling edge detection but not both. Separating this would require inventing yet another flags for IRQ types. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18 13:59:31 +02:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: regmap-irq/gpio-max77620: add level-irq support Add level active IRQ support to regmap-irq irqchip. Change breaks existing regmap-irq type setting. Convert the existing drivers which use regmap-irq with trigger type setting (gpio-max77620) to work with this new approach. So we do not magically support level-active IRQs on gpio-max77620 - but add support to the regmap-irq for chips which support them =) We do not support distinguishing situation where HW supports rising and falling edge detection but not both. Separating this would require inventing yet another flags for IRQ types. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18 13:59:31 +02:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Add generic macro to define regmap_irq Add REGMAP_IRQ_REG macro in regmap.h to define regmap_irq structure easily for other driver module. Signed-off-by: Qipeng Zha <qipeng.zha@intel.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-09-15 00:39:17 +08:00
regmap: add a new macro:REGMAP_IRQ_REG_LINE(_id, _reg_bits) if there are lots of irqs for a device and the register addresses for these irqs is continuous, we can use this macro to initialize regmap_irq value. Signed-off-by: Tony Xie <tony.xie@rock-chips.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-30 18:07:56 +08:00
regmap: regmap-irq: Add main status register support There is bunch of devices with multiple logical blocks which can generate interrupts. It's not a rare case that the interrupt reason registers are arranged so that there is own status/ack/mask register for each logical block. In some devices there is also a 'main interrupt register(s)' which can indicate what sub blocks have interrupts pending. When such a device is connected via slow bus like i2c the main part of interrupt handling latency can be caused by bus accesses. On systems where it is expected that only one (or few) sub blocks have active interrupts we can reduce the latency by only reading the main register and those sub registers which have active interrupts. Support this with regmap-irq for simple cases where main register does not require acking or masking. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-22 11:42:24 +02:00
regmap-irq: Add get_irq_reg() callback Replace the internal sub_irq_reg() function with a public callback that drivers can use when they have more complex register layouts. The default implementation is regmap_irq_get_irq_reg_linear(), used if the chip doesn't provide its own callback. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-12-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:19 +01:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Allow setting IRQ domain name suffix When multiple IRQ domains are created from the same device-tree node they will get the same name based on the device-tree path. This will cause a naming collision in debugFS when IRQ domain specific entries are created. The regmap-IRQ creates per instance IRQ domains. This will lead to a domain name conflict when a device which provides more than one interrupt line uses the regmap-IRQ. Add support for specifying an IRQ domain name suffix when creating a regmap-IRQ controller. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/776bc4996969e5081bcf61b9bdb5517e537147a3.1723120028.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-08 15:36:28 +03:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: regmap-irq: Add main status register support There is bunch of devices with multiple logical blocks which can generate interrupts. It's not a rare case that the interrupt reason registers are arranged so that there is own status/ack/mask register for each logical block. In some devices there is also a 'main interrupt register(s)' which can indicate what sub blocks have interrupts pending. When such a device is connected via slow bus like i2c the main part of interrupt handling latency can be caused by bus accesses. On systems where it is expected that only one (or few) sub blocks have active interrupts we can reduce the latency by only reading the main register and those sub registers which have active interrupts. Support this with regmap-irq for simple cases where main register does not require acking or masking. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-22 11:42:24 +02:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap-irq: Fix inverted handling of unmask registers To me "unmask" suggests that we write 1s to the register when an interrupt is enabled. This also makes sense because it's the opposite of what the "mask" register does (write 1s to disable an interrupt). But regmap-irq does the opposite: for a disabled interrupt, it writes 1s to "unmask" and 0s to "mask". This is surprising and deviates from the usual way mask registers are handled. Additionally, mask_invert didn't interact with unmask registers properly -- it caused them to be ignored entirely. Fix this by making mask and unmask registers orthogonal, using the following behavior: * Mask registers are written with 1s for disabled interrupts. * Unmask registers are written with 1s for enabled interrupts. This behavior supports both normal or inverted mask registers and separate set/clear registers via different combinations of mask_base/unmask_base. The old unmask register behavior is deprecated. Drivers need to opt-in to the new behavior by setting mask_unmask_non_inverted. Warnings are issued if the driver relies on deprecated behavior. Chips that only set one of mask_base/unmask_base don't have to use the mask_unmask_non_inverted flag because that use case was previously not supported. The mask_invert flag is also deprecated in favor of describing inverted mask registers as unmask registers. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-11-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:18 +01:00
regmap: irq: Allow using zero value for ack_base In some cases, clear interrupt register may be at address 0. This patch allows to use such configurations by adding additional configuration bit to indicate this. [With doc fix from Levente Kurusa <levex@linux.com> -- broonie] Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-12-15 13:36:51 +04:00
regmap: Implement support for wake IRQs Allow chips to provide a bank of registers for controlling the wake state in a similar fashion to the masks and propagate the wake count to the parent interrupt controller. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-05 14:34:03 +01:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap: add support for non contiguous status to regmap-irq In some chips the IRQ status registers are not contiguous in the register map but spaced at even spaces. This is an easy case to handle with minor changes. It is assume for this purpose that the stride for status is equal to the stride for mask/ack registers as well. Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-14 22:40:43 +09:00
regmap: irq: Allow to acknowledge masked interrupts during initialization In case the hardware interrupt mask register does not prevent the chip level irq from being asserted by the corresponding interrupt status bit, already set interrupt bits should to be cleared once after masking them during initialization. Add a flag to let drivers enable this behavior. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-07-22 17:15:52 +02:00
regmap-irq: Fix inverted handling of unmask registers To me "unmask" suggests that we write 1s to the register when an interrupt is enabled. This also makes sense because it's the opposite of what the "mask" register does (write 1s to disable an interrupt). But regmap-irq does the opposite: for a disabled interrupt, it writes 1s to "unmask" and 0s to "mask". This is surprising and deviates from the usual way mask registers are handled. Additionally, mask_invert didn't interact with unmask registers properly -- it caused them to be ignored entirely. Fix this by making mask and unmask registers orthogonal, using the following behavior: * Mask registers are written with 1s for disabled interrupts. * Unmask registers are written with 1s for enabled interrupts. This behavior supports both normal or inverted mask registers and separate set/clear registers via different combinations of mask_base/unmask_base. The old unmask register behavior is deprecated. Drivers need to opt-in to the new behavior by setting mask_unmask_non_inverted. Warnings are issued if the driver relies on deprecated behavior. Chips that only set one of mask_base/unmask_base don't have to use the mask_unmask_non_inverted flag because that use case was previously not supported. The mask_invert flag is also deprecated in favor of describing inverted mask registers as unmask registers. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-11-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:18 +01:00
regmap: irq: Allow using zero value for ack_base In some cases, clear interrupt register may be at address 0. This patch allows to use such configurations by adding additional configuration bit to indicate this. [With doc fix from Levente Kurusa <levex@linux.com> -- broonie] Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-12-15 13:36:51 +04:00
regmap: irq: add ack_invert flag for chips using cleared bits as ack An user will be CSR SiRFSoC ARM chips. Signed-off-by: Guo Zeng <Guo.Zeng@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-17 05:23:21 +00:00
regmap: irq: Add support to clear ack registers For particular codec HWs have requirement to toggle interrupt clear register twice 0->1->0. To accommodate it, need to add one more field (clear_ack) in the regmap_irq struct and update regmap-irq driver to support it. Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org> Link: https://lore.kernel.org/r/1601907440-13373-1-git-send-email-lkasam@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05 19:47:19 +05:30
regmap-irq: Place kernel doc of struct regmap_irq_chip in order It seems that a couple of members got lost theirorder, put them back. Besides that, split field descriptions into groups in the same way as it's done in the structure definition. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230220153334.87049-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-20 17:33:34 +02:00
regmap: irq: Add support for chips without separate IRQ status Some GPIO chips allow to rise an IRQ on GPIO level changes but do not provide an IRQ status for each separate line: only the current gpio level can be retrieved. Add support for these chips, emulating IRQ status by comparing GPIO levels with the levels during the previous interrupt. Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250522-mdb-max7360-support-v9-5-74fc03517e41@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-22 14:06:20 +02:00
regmap: irq: Correct documentation of wake_invert flag Per commit 9442490a0286 ("regmap: irq: Support wake IRQ mask inversion") the wake_invert flag is to support enable register, so cleared bits are wake disabled. Fixes: 68622bdfefb9 ("regmap: irq: document mask/wake_invert flags") Cc: stable@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org> Link: https://patch.msgid.link/20251024082344.2188895-1-shawnguo2@yeah.net Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-24 16:23:44 +08:00
regmap-irq: Remove an unnecessary restriction on type_in_mask Check types_supported instead of checking type_rising/falling_val when using type_in_mask interrupts. This makes the intent clearer and allows a type_in_mask irq to support level or edge triggers, rather than only edge triggers. Update the documentation and comments to reflect the new behavior. This shouldn't affect existing drivers, because if they didn't set types_supported properly the type buffer wouldn't be updated. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-5-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:12 +01:00
regmap: irq: add an option to clear status registers on unmask Some interrupt controllers whose interrupts are acked on read will set the status bits for masked interrupts without changing the state of the IRQ line. Some chips have an additional "feature" where if those set bits are not cleared before unmasking their respective interrupts, the IRQ line will change the state and we'll interpret this as an interrupt although it actually fired when it was masked. Add a new field to the irq chip struct that tells the regmap irq chip code to always clear the status registers before actually changing the irq mask values. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-19 12:18:05 +01:00
regmap-irq: Place kernel doc of struct regmap_irq_chip in order It seems that a couple of members got lost theirorder, put them back. Besides that, split field descriptions into groups in the same way as it's done in the structure definition. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230220153334.87049-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-20 17:33:34 +02:00
regmap-irq: Add no_status support Some devices lack status registers, yet expect to handle interrupts. Introduce a no_status flag to indicate such a configuration, where rather than read a status register to verify, all interrupts received are assumed to be active. Cc: Mark Brown <broonie@kernel.org> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/bd501b4b5ff88da24d467f75e8c71b4e0e6f21e2.1677515341.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-27 11:45:22 -05:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap-irq: Place kernel doc of struct regmap_irq_chip in order It seems that a couple of members got lost theirorder, put them back. Besides that, split field descriptions into groups in the same way as it's done in the structure definition. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230220153334.87049-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-20 17:33:34 +02:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap-irq: Place kernel doc of struct regmap_irq_chip in order It seems that a couple of members got lost theirorder, put them back. Besides that, split field descriptions into groups in the same way as it's done in the structure definition. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230220153334.87049-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-20 17:33:34 +02:00
regmap: irq: Add support to call client specific pre/post interrupt service Regmap irq implements the generic interrupt service routine which is common for most of devices. Some devices, like MAX77620, MAX20024 needs the special handling before and after servicing the interrupt as generic. For the example, MAX77620 programming guidelines for interrupt servicing says: 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting GLBLM. 2. Read IRQTOP and service the interrupt accordingly. 3. Once all interrupts has been checked and serviced, the interrupt service routine un-masks the hardware interrupt line by clearing GLBLM. The step (2) is implemented in regmap irq as generic routine. For step (1) and (3), add callbacks from regmap irq to client driver to handle chip specific configurations. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-20 20:40:26 +05:30
regmap-irq: Add handle_mask_sync() callback Provide a public callback handle_mask_sync() that drivers can use when they have more complex IRQ masking logic. The default implementation is regmap_irq_handle_mask_sync(), used if the chip doesn't provide its own callback. Cc: Mark Brown <broonie@kernel.org> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/e083474b3d467a86e6cb53da8072de4515bd6276.1669100542.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-22 02:10:59 -05:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap-irq: Add get_irq_reg() callback Replace the internal sub_irq_reg() function with a public callback that drivers can use when they have more complex register layouts. The default implementation is regmap_irq_get_irq_reg_linear(), used if the chip doesn't provide its own callback. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-12-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:19 +01:00
regmap-irq: Fix typo in documentation for .get_irq_reg() It refers to a non-existent "num_type_settings" value, which is an old name I'd used during development of config registers and later dropped because it wasn't very clear. The correct bound for the range is num_config_regs, which can be verified by checking the implementation. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com Link: https://lore.kernel.org/r/20230509110100.3980123-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-09 12:00:55 +01:00
regmap-irq: Add get_irq_reg() callback Replace the internal sub_irq_reg() function with a public callback that drivers can use when they have more complex register layouts. The default implementation is regmap_irq_get_irq_reg_linear(), used if the chip doesn't provide its own callback. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-12-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:19 +01:00
regmap: irq: Add support to call client specific pre/post interrupt service Regmap irq implements the generic interrupt service routine which is common for most of devices. Some devices, like MAX77620, MAX20024 needs the special handling before and after servicing the interrupt as generic. For the example, MAX77620 programming guidelines for interrupt servicing says: 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting GLBLM. 2. Read IRQTOP and service the interrupt accordingly. 3. Once all interrupts has been checked and serviced, the interrupt service routine un-masks the hardware interrupt line by clearing GLBLM. The step (2) is implemented in regmap irq as generic routine. For step (1) and (3), add callbacks from regmap irq to client driver to handle chip specific configurations. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-20 20:40:26 +05:30
regmap: Fixup the kernel-doc comments on functions/structures Most of the kernel-doc comments in regmap don't actually generate correctly. This patch fixes up a few common issues, corrects some typos and adds some missing argument descriptions. The most common issues being using a : after the function name which causes the short description to not render correctly and not separating the long and short descriptions of the function. There are quite a few instances of arguments not being described or given the wrong name as well. This patch doesn't fixup functions/structures that are currently missing descriptions. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-01-12 11:17:39 +00:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Allow setting IRQ domain name suffix When multiple IRQ domains are created from the same device-tree node they will get the same name based on the device-tree path. This will cause a naming collision in debugFS when IRQ domain specific entries are created. The regmap-IRQ creates per instance IRQ domains. This will lead to a domain name conflict when a device which provides more than one interrupt line uses the regmap-IRQ. Add support for specifying an IRQ domain name suffix when creating a regmap-IRQ controller. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/776bc4996969e5081bcf61b9bdb5517e537147a3.1723120028.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-08 15:36:28 +03:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: regmap-irq: Add main status register support There is bunch of devices with multiple logical blocks which can generate interrupts. It's not a rare case that the interrupt reason registers are arranged so that there is own status/ack/mask register for each logical block. In some devices there is also a 'main interrupt register(s)' which can indicate what sub blocks have interrupts pending. When such a device is connected via slow bus like i2c the main part of interrupt handling latency can be caused by bus accesses. On systems where it is expected that only one (or few) sub blocks have active interrupts we can reduce the latency by only reading the main register and those sub registers which have active interrupts. Support this with regmap-irq for simple cases where main register does not require acking or masking. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-22 11:42:24 +02:00
regmap-irq: handle const struct regmap_irq_sub_irq_map The struct instances supplied by the drivers are never modified. Handle them as const in the regmap core allowing the drivers to put them into .rodata. Also add a new entry to const_structs.checkpatch to make sure future instances of this struct already enter the tree as const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240706-regmap-const-structs-v1-2-d08c776da787@weissschuh.net Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-06 13:13:42 +02:00
regmap: regmap-irq: Add main status register support There is bunch of devices with multiple logical blocks which can generate interrupts. It's not a rare case that the interrupt reason registers are arranged so that there is own status/ack/mask register for each logical block. In some devices there is also a 'main interrupt register(s)' which can indicate what sub blocks have interrupts pending. When such a device is connected via slow bus like i2c the main part of interrupt handling latency can be caused by bus accesses. On systems where it is expected that only one (or few) sub blocks have active interrupts we can reduce the latency by only reading the main register and those sub registers which have active interrupts. Support this with regmap-irq for simple cases where main register does not require acking or masking. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-22 11:42:24 +02:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: irq: add support for chips who have separate unmask registers Some chips have separate unmask registers from mask registers for some consideration of concurrency SMP write performance. And this patch adds a flag for it. An user will be CSR SiRFSoC ARM chips. Signed-off-by: Guo Zeng <Guo.Zeng@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-17 05:23:20 +00:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Implement support for wake IRQs Allow chips to provide a bank of registers for controlling the wake state in a similar fashion to the masks and propagate the wake count to the parent interrupt controller. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-05 14:34:03 +01:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap: add support for non contiguous status to regmap-irq In some chips the IRQ status registers are not contiguous in the register map but spaced at even spaces. This is an easy case to handle with minor changes. It is assume for this purpose that the stride for status is equal to the stride for mask/ack registers as well. Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-14 22:40:43 +09:00
regmap-irq: Convert bool bitfields to unsigned int Use 'unsigned int' for bitfields for consistency with most other kernel code. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:09 +01:00
regmap-irq: Fix inverted handling of unmask registers To me "unmask" suggests that we write 1s to the register when an interrupt is enabled. This also makes sense because it's the opposite of what the "mask" register does (write 1s to disable an interrupt). But regmap-irq does the opposite: for a disabled interrupt, it writes 1s to "unmask" and 0s to "mask". This is surprising and deviates from the usual way mask registers are handled. Additionally, mask_invert didn't interact with unmask registers properly -- it caused them to be ignored entirely. Fix this by making mask and unmask registers orthogonal, using the following behavior: * Mask registers are written with 1s for disabled interrupts. * Unmask registers are written with 1s for enabled interrupts. This behavior supports both normal or inverted mask registers and separate set/clear registers via different combinations of mask_base/unmask_base. The old unmask register behavior is deprecated. Drivers need to opt-in to the new behavior by setting mask_unmask_non_inverted. Warnings are issued if the driver relies on deprecated behavior. Chips that only set one of mask_base/unmask_base don't have to use the mask_unmask_non_inverted flag because that use case was previously not supported. The mask_invert flag is also deprecated in favor of describing inverted mask registers as unmask registers. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-11-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:18 +01:00
regmap-irq: Convert bool bitfields to unsigned int Use 'unsigned int' for bitfields for consistency with most other kernel code. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:09 +01:00
regmap-irq: Place kernel doc of struct regmap_irq_chip in order It seems that a couple of members got lost theirorder, put them back. Besides that, split field descriptions into groups in the same way as it's done in the structure definition. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230220153334.87049-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-20 17:33:34 +02:00
regmap: irq: Add support for chips without separate IRQ status Some GPIO chips allow to rise an IRQ on GPIO level changes but do not provide an IRQ status for each separate line: only the current gpio level can be retrieved. Add support for these chips, emulating IRQ status by comparing GPIO levels with the levels during the previous interrupt. Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250522-mdb-max7360-support-v9-5-74fc03517e41@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-22 14:06:20 +02:00
regmap-irq: Convert bool bitfields to unsigned int Use 'unsigned int' for bitfields for consistency with most other kernel code. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:09 +01:00
regmap-irq: Place kernel doc of struct regmap_irq_chip in order It seems that a couple of members got lost theirorder, put them back. Besides that, split field descriptions into groups in the same way as it's done in the structure definition. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230220153334.87049-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-20 17:33:34 +02:00
regmap-irq: Add no_status support Some devices lack status registers, yet expect to handle interrupts. Introduce a no_status flag to indicate such a configuration, where rather than read a status register to verify, all interrupts received are assumed to be active. Cc: Mark Brown <broonie@kernel.org> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/bd501b4b5ff88da24d467f75e8c71b4e0e6f21e2.1677515341.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-27 11:45:22 -05:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: irq: add support for configuration of trigger type Some of devices supports the trigger level for interrupt like rising/falling edge specially for GPIOs. The interrupt support of such devices may have uses the generic regmap irq framework for implementation. Add support to configure the trigger type device interrupt register via regmap-irq framework. The regmap-irq framework configures the trigger register only if the details of trigger type registers are provided. [Fixed use of terery operator for legibility -- broonie] Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-12-22 18:25:26 +05:30
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap: irq: Add support to call client specific pre/post interrupt service Regmap irq implements the generic interrupt service routine which is common for most of devices. Some devices, like MAX77620, MAX20024 needs the special handling before and after servicing the interrupt as generic. For the example, MAX77620 programming guidelines for interrupt servicing says: 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting GLBLM. 2. Read IRQTOP and service the interrupt accordingly. 3. Once all interrupts has been checked and serviced, the interrupt service routine un-masks the hardware interrupt line by clearing GLBLM. The step (2) is implemented in regmap irq as generic routine. For step (1) and (3), add callbacks from regmap irq to client driver to handle chip specific configurations. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-20 20:40:26 +05:30
regmap-irq: Drop map from handle_mask_sync() parameters Remove the map parameter from the struct regmap_irq_chip callback handle_mask_sync() because it can be passed via the irq_drv_data parameter instead. The gpio-104-dio-48e driver is the only consumer of this callback and is thus updated accordingly. Reviewed-by: Linus Walleij <linus.walleij@linaro.org Signed-off-by: William Breathitt Gray <william.gray@linaro.org Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com Link: https://lore.kernel.org/r/1f44fb0fbcd3dccea3371215b00f1b9a956c1a12.1679323449.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org
2023-04-07 07:47:33 -04:00
regmap-irq: Add handle_mask_sync() callback Provide a public callback handle_mask_sync() that drivers can use when they have more complex IRQ masking logic. The default implementation is regmap_irq_handle_mask_sync(), used if the chip doesn't provide its own callback. Cc: Mark Brown <broonie@kernel.org> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/e083474b3d467a86e6cb53da8072de4515bd6276.1669100542.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-22 02:10:59 -05:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap: Pass irq_drv_data as a parameter for set_type_config() Allow the struct regmap_irq_chip set_type_config() callback to access irq_drv_data by passing it as a parameter. Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20e15cd3afae80922b7e0577c7741df86b3390c5.1680708357.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-04-05 11:45:42 -04:00
regmap-irq: Add get_irq_reg() callback Replace the internal sub_irq_reg() function with a public callback that drivers can use when they have more complex register layouts. The default implementation is regmap_irq_get_irq_reg_linear(), used if the chip doesn't provide its own callback. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-12-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:19 +01:00
regmap: irq: Add support to call client specific pre/post interrupt service Regmap irq implements the generic interrupt service routine which is common for most of devices. Some devices, like MAX77620, MAX20024 needs the special handling before and after servicing the interrupt as generic. For the example, MAX77620 programming guidelines for interrupt servicing says: 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting GLBLM. 2. Read IRQTOP and service the interrupt accordingly. 3. Once all interrupts has been checked and serviced, the interrupt service routine un-masks the hardware interrupt line by clearing GLBLM. The step (2) is implemented in regmap irq as generic routine. For step (1) and (3), add callbacks from regmap irq to client driver to handle chip specific configurations. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-20 20:40:26 +05:30
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap-irq: Add get_irq_reg() callback Replace the internal sub_irq_reg() function with a public callback that drivers can use when they have more complex register layouts. The default implementation is regmap_irq_get_irq_reg_linear(), used if the chip doesn't provide its own callback. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-12-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:19 +01:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap: Pass irq_drv_data as a parameter for set_type_config() Allow the struct regmap_irq_chip set_type_config() callback to access irq_drv_data by passing it as a parameter. Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20e15cd3afae80922b7e0577c7741df86b3390c5.1680708357.git.william.gray@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-04-05 11:45:42 -04:00
regmap-irq: Introduce config registers for irq types Config registers provide a more uniform approach to handling irq type registers. They are essentially an extension of the virtual registers used by the qcom-pm8008 driver. Config registers can be represented as a 2D array: config_base[0] reg0,0 reg0,1 reg0,2 reg0,3 config_base[1] reg1,0 reg1,1 reg1,2 reg1,3 config_base[2] reg2,0 reg2,1 reg2,2 reg2,3 There are 'num_config_bases' base registers, each of which is used to address 'num_config_regs' registers. The addresses are calculated in the same way as for other bases. It is assumed that an irq's type is controlled by one column of registers; that column is identified by the irq's 'type_reg_offset'. The set_type_config() callback is responsible for updating the config register contents. It receives an array of buffers (each represents a row of registers) and the index of the column to update, along with the 'struct regmap_irq' description and requested irq type. Buffered values are written to registers in regmap_irq_sync_unlock(). Note that the entire register contents are overwritten, which is a minor change in behavior from type registers via 'type_base'. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-9-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23 22:14:16 +01:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: Constify regmap_irq_chip We should never be modifying it and it lets drivers declare it const. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-31 21:01:46 +01:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap-irq: use fwnode instead of device node in add_irq_chip() Convert the argument to the newer fwnode_handle instead a device tree node. Fortunately, there are no users for now. So this is an easy change. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200706175353.16404-2-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-06 19:53:41 +02:00
regmap: Add a reusable irq_chip for regmap based interrupt controllers There seem to be lots of regmap-using devices with very similar interrupt controllers with a small bank of interrupt registers and mask registers with an interrupt per bit. This won't cover everything but it's a good start. Each chip supplies a base for the status registers, a base for the mask registers, an optional base for writing acknowledgements (which may be the same as the status registers) and an array of bits within each of these register banks which indicate the interrupt. There is an assumption that the bit for each interrupt will be the same in each of the register bank. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-10-28 23:50:49 +02:00
regmap: irq: add devm apis for regmap_{add,del}_irq_chip Add device managed APIs for regmap_add_irq_chip() and regmap_del_irq_chip() so that it can be managed by device framework for freeing it. This helps on following: 1. Maintaining the sequence of resource allocation and deallocation regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq) On free path: regmap_del_irq_chip(d); and then removing the irq registration. On this case, regmap irq is deleted before the irq is free. This force to use normal irq registration. By using devm apis, the sequence can be maintain properly: devm_regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq); and resource deallocation will be done in reverse order by device framework. 2. No need to delete the regmap_irq_chip in error path or remove callback and hence there is less code on this path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-10 14:29:50 +05:30
regmap-irq: use fwnode instead of device node in add_irq_chip() Convert the argument to the newer fwnode_handle instead a device tree node. Fortunately, there are no users for now. So this is an easy change. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200706175353.16404-2-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-06 19:53:41 +02:00
regmap: irq: add devm apis for regmap_{add,del}_irq_chip Add device managed APIs for regmap_add_irq_chip() and regmap_del_irq_chip() so that it can be managed by device framework for freeing it. This helps on following: 1. Maintaining the sequence of resource allocation and deallocation regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq) On free path: regmap_del_irq_chip(d); and then removing the irq registration. On this case, regmap irq is deleted before the irq is free. This force to use normal irq registration. By using devm apis, the sequence can be maintain properly: devm_regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq); and resource deallocation will be done in reverse order by device framework. 2. No need to delete the regmap_irq_chip in error path or remove callback and hence there is less code on this path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-10 14:29:50 +05:30
regmap: Add irq_base accessor to regmap_irq Allows devices to discover their own interrupt without having to remember it themselves. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-12-05 16:10:15 +00:00
regmap: Convert regmap_irq to use irq_domain This gets us up to date with the recommended current kernel infrastructure and should transparently give us device tree interrupt bindings for any devices using the framework. If an explicit IRQ mapping is passed in then a legacy interrupt range is created, otherwise a simple linear mapping is used. Previously a mapping was mandatory so existing drivers should not be affected. A function regmap_irq_get_virq() is provided to allow drivers to map individual IRQs which should be used in preference to the existing regmap_irq_chip_get_base() which is only valid if a legacy IRQ range is provided. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-13 10:59:56 +01:00
regmap: irq: Allow users to retrieve the irq_domain This is useful for integration with other subsystems, especially MFD, and provides an alternative API for users that request their own IRQs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-20 21:45:05 +01:00
regmap: Allow drivers to control cache_only flag Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 18:22:14 +01:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: Provide asynchronous write and update bits operations Make it easier for drivers to include single register writes in asynchronous sequences by providing async versions of the write and update bits operations. The update bits operations are only likely to be effective when used with devices that have caches but this is common enough to be useful. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-09 13:30:10 +01:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08: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: 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 stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: Add regmap_read_bypassed() Add a regmap_read_bypassed() to allow reads from the hardware registers while the regmap is in cache-only mode. A typical use for this is to keep the cache in cache-only mode until the hardware has reached a valid state, but one or more status registers must be polled to determine when this state is reached. For example, firmware download on the cs35l56 can take several seconds if there are multiple amps sharing limited bus bandwidth. This is too long to block in probe() so it is done as a background task. The device must be soft-reset to reboot the firmware and during this time the registers are not accessible, so the cache should be in cache-only. But the driver must poll a register to detect when reboot has completed. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 8a731fd37f8b ("ASoC: cs35l56: Move utility functions to shared file") Link: https://msgid.link/r/20240408101803.43183-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-08 11:18:00 +01:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08: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 stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: add regmap_update_bits_base() Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch adds new regmap_update_bits_base() which is feature merged function. Above functions can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15 05:22:18 +00:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: provide helpers for simple bit operations In many instances regmap_update_bits() is used for simple bit setting and clearing. In these cases the last argument is redundant and we can hide it with a static inline function. This adds three new helpers for simple bit operations: set_bits, clear_bits and test_bits (the last one defined as a regular function). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200528154503.26304-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-28 17:45:02 +02:00
regmap: provide regmap_assign_bits() Add another bits helper to regmap API: this one sets given bits if value is true and clears them if it's false. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/20241108-assign-bits-v1-1-382790562d99@ideasonboard.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08 16:07:37 +02:00
regmap: provide helpers for simple bit operations In many instances regmap_update_bits() is used for simple bit setting and clearing. In these cases the last argument is redundant and we can hide it with a static inline function. This adds three new helpers for simple bit operations: set_bits, clear_bits and test_bits (the last one defined as a regular function). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200528154503.26304-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-28 17:45:02 +02:00
regmap: add regmap_field_update_bits_base() This patch adds new regmap_field_update_bits_base() which is using regmap_update_bits_base(). Current regmap_field_xxx() can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15 05:23:55 +00:00
regmap: add regmap_write_bits() regmap_write_bits() is similar to regmap_update_bits(), but regmap_write_bits() write data to register even though it is same value. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-16 08:52:39 +00:00
regmap: add regmap_fields_update_bits_base() This patch adds new regmap_fields_update_bits_base() which is using regmap_update_bits_base(). Current regmap_fields_xxx() can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15 05:24:51 +00:00
regmap: Provide asynchronous write and update bits operations Make it easier for drivers to include single register writes in asynchronous sequences by providing async versions of the write and update bits operations. The update bits operations are only likely to be effective when used with devices that have caches but this is common enough to be useful. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-09 13:30:10 +01:00
regmap: convert all regmap_update_bits() and co. macros to static inlines There's no reason to have these as macros. Let's convert them all to static inlines for better readability and stronger typing. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200615072313.11106-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15 09:23:13 +02:00
regmap: provide regmap_field helpers for simple bit operations We have set/clear/test operations for regmap, but not for regmap_field yet. So let's introduce regmap_field helpers too. In many instances regmap_field_update_bits() is used for simple bit setting and clearing. In these cases the last argument is redundant and we can hide it with a static inline function. This adds three new helpers for simple bit operations: set_bits, clear_bits and test_bits (the last one defined as a regular function). Signed-off-by: Li Chen <lchen@ambarella.com> Link: https://lore.kernel.org/r/180eef422c3.deae9cd960729.8518395646822099769@zohomail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-22 20:26:58 -07:00
regmap: convert all regmap_update_bits() and co. macros to static inlines There's no reason to have these as macros. Let's convert them all to static inlines for better readability and stronger typing. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200615072313.11106-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15 09:23:13 +02:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: Introduce regmap_get_max_register This patch introduces regmap_get_max_register() function which would be used by the infrastructures like nvmem framework built on top of regmap. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-21 17:42:43 +01:00
regmap: Introduce regmap_get_reg_stride This patch introduces regmap_get_reg_stride() function which would be used by the infrastructures like nvmem framework built on top of regmap. Mostly this function would be used for sanity checks on inputs within such infrastructure. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-05-21 17:42:54 +01:00
regmap: add regmap_might_sleep() With the dawn of MMIO gpio-regmap users, it is desirable to let gpio-regmap ask the regmap if it might sleep during an access so it can pass that information to gpiochip. Add a new regmap_might_sleep() to query the regmap. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20221121150843.1562603-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-21 16:08:42 +01:00
regcache: Add support for sorting defaults arrays The defaults array in regcache must be sorted into ascending register address order, because binary search is used to locate values in the array. Add a helper to sort the register defaults array which can be useful for systems that dynamically create a defaults array based on external information. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-17 14:01:56 +00:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: Add stub for regcache_sync_region() Added on another branch. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-23 19:49:43 +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: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08: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: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: Fix leftover from struct reg_default to struct reg_sequence change In 8019ff6cfc04 ("regmap: Use reg_sequence for multi_reg_write / register_patch") struct reg_default was renamed to struct reg_secquence, which missed one place to fix up. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-30 16:20:15 +01:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: add regmap_parse_val api In some cases, we need regmap's format parse_val function to do be/le translation according to the bus configuration. For example, snd_soc_bytes_put() uses regmap to write/read values, and use cpu_to_be() directly to covert MASK into big endian. This is a defect, and should use regmap's format function to do it according to bus configuration. Signed-off-by: Nenghua Cao <nhcao@marvell.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-02-19 18:44:13 +08: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: Add regmap_get_device Add a new function regmap_get_device to obtain the underlying struct device from a regmap. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-21 18:38:47 +03:00
regmap: Fix return code for stub regmap_get_device() We return a pointer, not an int. Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-25 19:01:53 +01:00
regmap: Add regmap_get_device Add a new function regmap_get_device to obtain the underlying struct device from a regmap. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-21 18:38:47 +03:00
regmap: Add stub regmap calls as a build crutch for infrastructure users Make life easier for subsystems which build infrastructure on top of the regmap API by providing stub definitions for most of the API so that users can at least build even if the regmap API is not enabled without having to add ifdefs if they don't want to. These stubs are not expected to be useful and should never actually get called, they just exist so that we can link so there are WARN_ONCE()s in the stubs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-02-17 14:49:51 -08:00
regmap: Add generic non-memory mapped register access API There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams. We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that. This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason. As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2011-05-11 19:59:58 +02:00