mirrors
/
linux-stable
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
1
0
Fork 0
Code Issues Releases Wiki Activity
linux-stable/drivers/base/regmap/Kconfig

68 lines
1.2 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
# SPDX-License-Identifier: GPL-2.0
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 17:59:58 +00:00
# Generic register map support. There are no user servicable options here,
# this is an API intended to be used by other kernel subsystems. These
# subsystems should select the appropriate symbols.
config REGMAP
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 19:28:03 +00:00
default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_W1 || REGMAP_AC97 || REGMAP_MMIO || REGMAP_IRQ || REGMAP_SOUNDWIRE || REGMAP_SOUNDWIRE_MBQ || REGMAP_SCCB || REGMAP_I3C || REGMAP_SPI_AVMM || REGMAP_MDIO)
regmap: make LZO cache optional Commit 2cbbb579bcbe3 ("regmap: Add the LZO cache support") added support for LZO compression in regcache, but there were never any users added afterwards. Since LZO support itself has its own size, it currently is rather a deoptimization. So make it optional by introducing a symbol that can be selected by drivers wanting to make use of it. Saves e.g. ~46 kB on MIPS (size of LZO support + regcache LZO code). Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-02 13:15:37 +00:00
select IRQ_DOMAIN if REGMAP_IRQ
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 19:28:03 +00:00
select MDIO_BUS if REGMAP_MDIO
regmap: make LZO cache optional Commit 2cbbb579bcbe3 ("regmap: Add the LZO cache support") added support for LZO compression in regcache, but there were never any users added afterwards. Since LZO support itself has its own size, it currently is rather a deoptimization. So make it optional by introducing a symbol that can be selected by drivers wanting to make use of it. Saves e.g. ~46 kB on MIPS (size of LZO support + regcache LZO code). Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-02 13:15:37 +00:00
bool
config REGCACHE_COMPRESSED
regmap: Add the LZO cache support This patch adds support for LZO compression when storing the register cache. For a typical device whose register map would normally occupy 25kB or 50kB by using the LZO compression technique, one can get down to ~5-7kB. There might be a performance penalty associated with each individual read/write due to decompressing/compressing the underlying cache, however that should not be noticeable. These memory benefits depend on whether the target architecture can get rid of the memory occupied by the original register defaults cache which is marked as __devinitconst. Nevertheless there will be some memory gain even if the target architecture can't get rid of the original register map, this should be around ~30-32kB instead of 50kB. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-09-19 13:34:03 +00:00
select LZO_COMPRESS
select LZO_DECOMPRESS
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 17:59:58 +00:00
bool
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 18:02:29 +00: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 18:45:51 +00:00
config REGMAP_AC97
tristate
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 18:02:29 +00:00
config REGMAP_I2C
tristate
regmap: Add explicit dependencies to catch "select" misuse Add explicit dependencies for the various regmap modules, so Kconfig will print a warning message when another module selects a regmap module without fulfilling its dependencies. Without this, it's much more difficult to find out which module did the offending select. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-08-17 10:08:57 +00:00
depends on I2C
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 09:42:10 +00: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
config REGMAP_SLIMBUS
tristate
depends on SLIMBUS
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 09:42:10 +00:00
config REGMAP_SPI
tristate
regmap: Add explicit dependencies to catch "select" misuse Add explicit dependencies for the various regmap modules, so Kconfig will print a warning message when another module selects a regmap module without fulfilling its dependencies. Without this, it's much more difficult to find out which module did the offending select. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-08-17 10:08:57 +00:00
depends on SPI
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 21:50:49 +00: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 18:12:35 +00:00
config REGMAP_SPMI
tristate
regmap: Add explicit dependencies to catch "select" misuse Add explicit dependencies for the various regmap modules, so Kconfig will print a warning message when another module selects a regmap module without fulfilling its dependencies. Without this, it's much more difficult to find out which module did the offending select. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-08-17 10:08:57 +00:00
depends on SPMI
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 18:12:35 +00: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 07:06:27 +00:00
config REGMAP_W1
tristate
depends on W1
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 19:28:03 +00:00
config REGMAP_MDIO
tristate
regmap: add MMIO bus support This is a basic memory-mapped-IO bus for regmap. It has the following features and limitations: * Registers themselves may be 8, 16, 32, or 64-bit. 64-bit is only supported on 64-bit platforms. * Register offsets are limited to precisely 32-bit. * IO is performed using readl/writel, with no provision for using the __raw_readl or readl_relaxed variants. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-04 21:48:31 +00:00
config REGMAP_MMIO
tristate
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 21:50:49 +00:00
config REGMAP_IRQ
bool
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 10:20:59 +00:00
config REGMAP_SOUNDWIRE
tristate
soundwire: fix regmap dependencies and align with other serial links The existing code has a mixed select/depend usage which makes no sense. config SOUNDWIRE_BUS tristate select REGMAP_SOUNDWIRE config REGMAP_SOUNDWIRE tristate depends on SOUNDWIRE_BUS Let's remove one layer of Kconfig definitions and align with the solutions used by all other serial links. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190718230215.18675-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-07-18 23:02:15 +00:00
depends on SOUNDWIRE
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-16 15:47:48 +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-03 17:22:23 +00:00
config REGMAP_SOUNDWIRE_MBQ
tristate
depends on SOUNDWIRE
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-16 15:47:48 +00:00
config REGMAP_SCCB
tristate
depends on I2C
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 15:12:02 +00:00
config REGMAP_I3C
tristate
depends on I3C
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 07:34:56 +00:00
config REGMAP_SPI_AVMM
tristate
depends on SPI