summaryrefslogtreecommitdiff
path: root/include/linux/regmap.h
AgeCommit message (Collapse)AuthorFilesLines
2022-12-09regmap-irq: Add handle_mask_sync() callbackWilliam Breathitt Gray1-0/+5
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-25fsi: Add regmap and refactor sbefifoMark Brown1-0/+37
Merge series from Eddie James <eajames@linux.ibm.com>: The SBEFIFO hardware can now be attached over a new I2C endpoint interface called the I2C Responder (I2CR). In order to use the existing SBEFIFO driver, add a regmap driver for the FSI bus and an endpoint driver for the I2CR. Then, refactor the SBEFIFO and OCC drivers to clean up and use the new regmap driver or the I2CR interface. This branch just has the regmap change so it can be shared with the FSI code.
2022-11-25regmap: Add FSI bus supportEddie James1-0/+37
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-22regmap: add regmap_might_sleep()Michael Walle1-0/+7
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-08-17regmap: Support accelerated noinc operationsLinus Walleij1-0/+8
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-15regmap: mmio: Introduce IO accessors that can talk to IO portAndy Shevchenko1-0/+3
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-06-29regmap-irq: Deprecate the not_fixed_stride flagAidan MacDonald1-2/+4
This flag is a bit of a hack and the same thing can be accomplished using a custom ->get_irq_reg() callback. Add a warning to catch any use of the flag. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-13-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regmap-irq: Add get_irq_reg() callbackAidan MacDonald1-2/+13
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-29regmap-irq: Fix inverted handling of unmask registersAidan MacDonald1-3/+15
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-29regmap-irq: Deprecate type registers and virtual registersAidan MacDonald1-6/+12
Config registers can be used to replace both type and virtual registers, so mark both features are deprecated and issue a warning if they're used. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-10-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regmap-irq: Introduce config registers for irq typesAidan MacDonald1-0/+12
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-29regmap-irq: Remove mask_writeonly and regmap_irq_update_bits()Aidan MacDonald1-2/+0
Commit a71411dbf6c8 ("regmap: irq: add chip option mask_writeonly") introduced the mask_writeonly option, but it isn't used now and it appears it's never been used by any in-tree drivers. The motivation for the option is mentioned in the commit message, Some irq controllers have writeonly/multipurpose register layouts. In those cases we read invalid data back. [...] The option causes mask register updates to use regmap_write_bits() instead of regmap_update_bits(). However, regmap_write_bits() doesn't solve the reading invalid data problem. It's still a read-modify-write op like regmap_update_bits(). The difference is that 'update bits' will only write the new value if it is different from the current value, while 'write bits' will write the new value unconditionally, even if it's the same as the current value. This seems like a bit of a specialized use case and probably isn't that useful for regmap-irq, so let's just remove the option and go back to using an 'update bits' op for the mask registers. We can always add the option back if some driver ends up needing it in the future. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-7-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regmap-irq: Remove an unnecessary restriction on type_in_maskAidan MacDonald1-3/+5
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-29regmap-irq: Remove unused type_reg_stride fieldAidan MacDonald1-3/+0
It appears that no chip ever required a nonzero type_reg_stride and commit 1066cfbdfa3f ("regmap-irq: Extend sub-irq to support non-fixed reg strides") broke support. Just remove the field. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220623211420.918875-3-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regmap-irq: Convert bool bitfields to unsigned intAidan MacDonald1-13/+13
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-15regmap: provide regmap_field helpers for simple bit operationsLi Chen1-0/+37
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-05regmap: Add bulk read/write callbacks into regmap_configMarek Vasut1-0/+12
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-03-18regmap: allow a defined reg_base to be added to every addressColin Foster1-0/+3
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-18regmap: add configurable downshift for addressesColin Foster1-0/+3
Add an additional reg_downshift to be applied to register addresses before any register accesses. An example of a device that uses this is a VSC7514 chip, which require each register address to be downshifted by two if the access is performed over a SPI bus. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20220313224524.399947-2-colin.foster@in-advantage.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-15regmap: allow to define reg_update_bits for no bus configurationAnsuel Smith1-0/+7
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-08-26Merge series "Use raw spinlocks in the ls-extirq driver" from Vladimir ↵Mark Brown1-0/+2
Oltean <vladimir.oltean@nxp.com>: The ls-extirq irqchip driver accesses regmap inside its implementation of the struct irq_chip :: irq_set_type method, and currently regmap only knows to lock using normal spinlocks. But the method above wants raw spinlock context, so this isn't going to work and triggers a "[ BUG: Invalid wait context ]" splat. The best we can do given the arrangement of the code is to patch regmap and the syscon driver: regmap to support raw spinlocks, and syscon to request them on behalf of its ls-extirq consumer. Link: https://lore.kernel.org/lkml/20210825135438.ubcuxm5vctt6ne2q@skbuf/T/#u Vladimir Oltean (2): regmap: teach regmap to use raw spinlocks if requested in the config mfd: syscon: request a regmap with raw spinlocks for some devices drivers/base/regmap/internal.h | 4 ++++ drivers/base/regmap/regmap.c | 35 +++++++++++++++++++++++++++++----- drivers/mfd/syscon.c | 16 ++++++++++++++++ include/linux/regmap.h | 2 ++ 4 files changed, 52 insertions(+), 5 deletions(-) -- 2.25.1 base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5
2021-08-26regmap: teach regmap to use raw spinlocks if requested in the configVladimir Oltean1-0/+2
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-02regmap: allow const array for {devm_,}regmap_field_bulk_alloc reg_fieldsIcenowy Zheng1-2/+3
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-06-07regmap-irq: Introduce inverted status registers supportMaxim Kochetkov1-0/+2
Some interrupt controllers have inverted status register: cleared bits is active interrupts and set bits is inactive interrupts, so add inverted status support to the framework. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Link: https://lore.kernel.org/r/20210525034204.5272-1-fido_max@inbox.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-19Merge series "RTL8231 GPIO expander support" from Sander Vanheule ↵Mark Brown1-0/+36
<sander@svanheule.net>: The RTL8231 GPIO and LED expander can be configured for use as an MDIO or SMI bus device. Currently only the MDIO mode is supported, although SMI mode support should be fairly straightforward, once an SMI bus driver is available. Provided features by the RTL8231: - Up to 37 GPIOs - Configurable drive strength: 8mA or 4mA (currently unsupported) - Input debouncing on high GPIOs (currently unsupported) - Up to 88 LEDs in multiple scan matrix groups - On, off, or one of six toggling intervals - "single-color mode": 2×36 single color LEDs + 8 bi-color LEDs - "bi-color mode": (12 + 2×6) bi-color LEDs + 24 single color LEDs - Up to one PWM output (currently unsupported) - Fixed duty cycle, 8 selectable frequencies (1.2kHz - 4.8kHz) Register access is provided through a new MDIO regmap provider. The GPIO controller uses gpio-regmap, although a patch is required to support a limitation of the chip. There remain some log warnings when probing the device, possibly due to the way I'm using the MFD subsystem. Would it be possible to avoid these? [ 2.602242] rtl8231-pinctrl: Failed to locate of_node [id: -2] [ 2.609380] rtl8231-pinctrl rtl8231-pinctrl.0.auto: no of_node; not parsing pinctrl DT When no 'leds' sub-node is specified: [ 2.922262] rtl8231-leds: Failed to locate of_node [id: -2] [ 2.967149] rtl8231-leds rtl8231-leds.1.auto: no of_node; not parsing pinctrl DT [ 2.975673] rtl8231-leds rtl8231-leds.1.auto: scan mode missing or invalid [ 2.983531] rtl8231-leds: probe of rtl8231-leds.1.auto failed with error -22 Changes since v1: - Reintroduce MDIO regmap, with fixed Kconfig dependencies - Add configurable dir/value order for gpio-regmap direction_out call - Drop allocations for regmap fields that are used only on init - Move some definitions to MFD header - Add PM ops to replace driver remove for MFD - Change pinctrl driver to (modified) gpio-regmap - Change leds driver to use fwnode Link: https://lore.kernel.org/lkml/cover.1620735871.git.sander@svanheule.net/ Changes since RFC: - Dropped MDIO regmap interface. I was unable to resolve the Kconfig dependency issue, so have reverted to using regmap_config.reg_read/write. - Added pinctrl support - Added LED support - Changed root device to MFD, with pinctrl and leds child devices. Root device is now an mdio_device driver. Link: https://lore.kernel.org/linux-gpio/cover.1617914861.git.sander@svanheule.net/ Sander Vanheule (7): regmap: Add MDIO bus support gpio: regmap: Add configurable dir/value order dt-bindings: leds: Binding for RTL8231 scan matrix dt-bindings: mfd: Binding for RTL8231 mfd: Add RTL8231 core device pinctrl: Add RTL8231 pin control and GPIO support leds: Add support for RTL8231 LED scan matrix .../bindings/leds/realtek,rtl8231-leds.yaml | 159 ++++++++ .../bindings/mfd/realtek,rtl8231.yaml | 202 ++++++++++ drivers/base/regmap/Kconfig | 6 +- drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-mdio.c | 57 +++ drivers/gpio/gpio-regmap.c | 20 +- drivers/leds/Kconfig | 10 + drivers/leds/Makefile | 1 + drivers/leds/leds-rtl8231.c | 293 ++++++++++++++ drivers/mfd/Kconfig | 9 + drivers/mfd/Makefile | 1 + drivers/mfd/rtl8231.c | 153 +++++++ drivers/pinctrl/Kconfig | 11 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-rtl8231.c | 377 ++++++++++++++++++ include/linux/gpio/regmap.h | 3 + include/linux/mfd/rtl8231.h | 57 +++ include/linux/regmap.h | 36 ++ 18 files changed, 1393 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/realtek,rtl8231-leds.yaml create mode 100644 Documentation/devicetree/bindings/mfd/realtek,rtl8231.yaml create mode 100644 drivers/base/regmap/regmap-mdio.c create mode 100644 drivers/leds/leds-rtl8231.c create mode 100644 drivers/mfd/rtl8231.c create mode 100644 drivers/pinctrl/pinctrl-rtl8231.c create mode 100644 include/linux/mfd/rtl8231.h base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 -- 2.31.1
2021-05-19regmap: Add MDIO bus supportSander Vanheule1-0/+36
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-14regmap-i2c: Set regmap max raw r/w from quirksLucas Tanure1-0/+2
Set regmap raw read/write from i2c quirks max read/write so regmap_raw_read/write can split the access into chunks Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210512135222.223203-1-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-31regmap-irq: Add driver callback to configure virtual regsGuru Das Srinagesh1-0/+4
Enable drivers to configure and modify "virtual" registers, which are non-standard registers that further configure irq type on some devices. Since they are non-standard, enable drivers to configure them according to their particular idiosyncrasies by specifying an optional callback function while registering with the framework. Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Link: https://lore.kernel.org/r/07e058cdec2297d15c95c825aa0263064d962d5a.1616613838.git.gurus@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-31regmap-irq: Introduce virtual regs to handle more config regsGuru Das Srinagesh1-0/+5
Add "virtual" registers support to handle any irq configuration registers in addition to the ones the framework currently supports (status, mask, unmask, wake, type and ack). These are non-standard registers that further configure irq type on some devices, so enable the framework to add a variable number of them. Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Link: https://lore.kernel.org/r/a1787067004b0e11cb960319082764397469215a.1616613838.git.gurus@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-18regmap-irq: Extend sub-irq to support non-fixed reg stridesGuru Das Srinagesh1-0/+7
Qualcomm's MFD chips have a top level interrupt status register and sub-irqs (peripherals). When a bit in the main status register goes high, it means that the peripheral corresponding to that bit has an unserviced interrupt. If the bit is not set, this means that the corresponding peripheral does not. Commit a2d21848d9211d ("regmap: regmap-irq: Add main status register support") introduced the sub-irq logic that is currently applied only when reading status registers, but not for any other functions like acking or masking. Extend the use of sub-irq to all other functions, with two caveats regarding the specification of offsets: - Each member of the sub_reg_offsets array should be of length 1 - The specified offsets should be the unequal strides for each sub-irq device. In QCOM's case, all the *_base registers are to be configured to the base addresses of the first sub-irq group, with offsets of each subsequent group calculated as a difference from these addresses. Continuing from the example mentioned in the cover letter: /* * Address of MISC_INT_MASK = 0x1011 * Address of TEMP_ALARM_INT_MASK = 0x2011 * Address of GPIO01_INT_MASK = 0x3011 * * Calculate offsets as: * offset_0 = 0x1011 - 0x1011 = 0 (to access MISC's * registers) * offset_1 = 0x2011 - 0x1011 = 0x1000 * offset_2 = 0x3011 - 0x1011 = 0x2000 */ static unsigned int sub_unit0_offsets[] = {0}; static unsigned int sub_unit1_offsets[] = {0x1000}; static unsigned int sub_unit2_offsets[] = {0x2000}; static struct regmap_irq_sub_irq_map chip_sub_irq_offsets[] = { REGMAP_IRQ_MAIN_REG_OFFSET(sub_unit0_offsets), REGMAP_IRQ_MAIN_REG_OFFSET(sub_unit0_offsets), REGMAP_IRQ_MAIN_REG_OFFSET(sub_unit0_offsets), }; static struct regmap_irq_chip chip_irq_chip = { --------8<-------- .not_fixed_stride = true, .mask_base = MISC_INT_MASK, .type_base = MISC_INT_TYPE, .ack_base = MISC_INT_ACK, .sub_reg_offsets = chip_sub_irq_offsets, --------8<-------- }; Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Link: https://lore.kernel.org/r/526562423eaa58b4075362083f561841f1d6956c.1615423027.git.gurus@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-26Merge series "regmap/SoundWire/ASoC: Add SoundWire SDCA support" from Bard ↵Mark Brown1-0/+35
Liao <yung-chuan.liao@linux.intel.com>: The MIPI SoundWire Device Class standard will define audio functionality beyond the scope of the existing SoundWire 1.2 standard, which is limited to the bus and interface. The description is inspired by the USB Audio Class, with "functions", "entities", "control selectors", "audio clusters". The main difference with the USB Audio class is that the devices are typically on a motherboard and descriptors stored in platform firmware instead of being retrieved from the device. The current set of devices managed in this patchset are conformant with the SDCA 0.6 specification and require dedicated drivers since the descriptors and platform firmware specification is not complete at this time. They do however rely on the hierarchical addressing required by the SDCA standard. Future devices conformant with SDCA 1.0 should rely on a class driver. This series adds support for the hierarchical SDCA addressing and extends regmap. It then provides 3 codecs for RT711-sdca headset codec, RT1316 amplifier and RT715-scda microphone codec. Note that the release of this code before the formal adoption of the SDCA 1.0 specification was formally endorsed by the MIPI Board to make sure there is no delay for Linux-based support of this specification. Jack Yu (1): ASoC/SoundWire: rt715-sdca: First version of rt715 sdw sdca codec driver Pierre-Louis Bossart (2): soundwire: SDCA: add helper macro to access controls regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ Shuming Fan (2): ASoC/SoundWire: rt1316: Add RT1316 SDCA vendor-specific driver ASoC/SoundWire: rt711-sdca: Add RT711 SDCA vendor-specific driver drivers/base/regmap/Kconfig | 6 +- drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-sdw-mbq.c | 101 ++ include/linux/regmap.h | 35 + include/linux/soundwire/sdw_registers.h | 32 + sound/soc/codecs/Kconfig | 20 + sound/soc/codecs/Makefile | 6 + sound/soc/codecs/rt1316-sdw.c | 756 ++++++++++++ sound/soc/codecs/rt1316-sdw.h | 115 ++ sound/soc/codecs/rt711-sdca-sdw.c | 424 +++++++ sound/soc/codecs/rt711-sdca-sdw.h | 101 ++ sound/soc/codecs/rt711-sdca.c | 1481 +++++++++++++++++++++++ sound/soc/codecs/rt711-sdca.h | 246 ++++ sound/soc/codecs/rt715-sdca-sdw.c | 278 +++++ sound/soc/codecs/rt715-sdca-sdw.h | 170 +++ sound/soc/codecs/rt715-sdca.c | 936 ++++++++++++++ sound/soc/codecs/rt715-sdca.h | 124 ++ 17 files changed, 4831 insertions(+), 1 deletion(-) create mode 100644 drivers/base/regmap/regmap-sdw-mbq.c create mode 100644 sound/soc/codecs/rt1316-sdw.c create mode 100644 sound/soc/codecs/rt1316-sdw.h create mode 100644 sound/soc/codecs/rt711-sdca-sdw.c create mode 100644 sound/soc/codecs/rt711-sdca-sdw.h create mode 100644 sound/soc/codecs/rt711-sdca.c create mode 100644 sound/soc/codecs/rt711-sdca.h create mode 100644 sound/soc/codecs/rt715-sdca-sdw.c create mode 100644 sound/soc/codecs/rt715-sdca-sdw.h create mode 100644 sound/soc/codecs/rt715-sdca.c create mode 100644 sound/soc/codecs/rt715-sdca.h base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec -- 2.17.1
2020-11-26regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQPierre-Louis Bossart1-0/+35
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-10-26regmap: mmio: add config option to allow relaxed MMIO accessesAdrian Ratiu1-0/+5
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-05regmap: irq: Add support to clear ack registersLaxminath Kasam1-0/+2
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-09-28Merge tag 'regmap-field-bulk-api' into regmap-5.10Mark Brown1-0/+11
regmap: Add a bulk field API Useful for devices with many fields.
2020-09-28regmap: add support to regmap_field_bulk_alloc/free apisSrinivas Kandagatla1-0/+11
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-02regmap: Add can_sleep configuration optionDmitry Osipenko1-0/+3
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-08-26regmap: add Intel SPI Slave to AVMM Bus Bridge supportXu Yilun1-0/+36
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-07-17regmap: fix duplicated word in <linux/regmap.h>Randy Dunlap1-1/+1
Change doubled word "be" to "to be". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/7ef41bfc-de3e-073a-8746-0b3fdf7628c0@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-08Merge branch 'topic/devnode' of ↵Mark Brown1-9/+12
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into regmap-5.9
2020-07-08regmap-irq: use fwnode instead of device node in add_irq_chip()Michael Walle1-9/+12
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-06-15regmap: convert all regmap_update_bits() and co. macros to static inlinesBartosz Golaszewski1-30/+192
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-05-29Merge series "regmap: provide simple bitops and use them in a driver" from ↵Mark Brown1-0/+36
Bartosz Golaszewski <brgl@bgdev.pl> Bartosz Golaszewski <bgolaszewski@baylibre.com>: From: Bartosz Golaszewski <bgolaszewski@baylibre.com> I noticed that oftentimes I use regmap_update_bits() for simple bit setting or clearing. In this case the fourth argument is superfluous as it's always 0 or equal to the mask argument. This series proposes to add simple bit operations for setting, clearing and testing specific bits with regmap. The second patch uses all three in a driver that got recently picked into the net-next tree. The patches obviously target different trees so - if you're ok with the change itself - I propose you pick the first one into your regmap tree for v5.8 and then I'll resend the second patch to add the first user for these macros for v5.9. v1 -> v2: - convert the new macros to static inline functions v2 -> v3: - drop unneeded ternary operator Bartosz Golaszewski (2): regmap: provide helpers for simple bit operations net: ethernet: mtk-star-emac: use regmap bitops drivers/base/regmap/regmap.c | 22 +++++ drivers/net/ethernet/mediatek/mtk_star_emac.c | 80 ++++++++----------- include/linux/regmap.h | 36 +++++++++ 3 files changed, 93 insertions(+), 45 deletions(-) base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136 -- 2.26.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-05-29Merge series "New DSA driver for VSC9953 Seville switch" from Vladimir ↵Mark Brown1-0/+8
Oltean <olteanv@gmail.com>: Looking at the Felix and Ocelot drivers, Maxim asked if it would be possible to use them as a base for a new driver for the switch inside NXP T1040. Turns out, it is! The result is a driver eerily similar to Felix. The biggest challenge seems to be getting register read/write API generic enough to cover such wild bitfield variations between hardware generations. There is a patch on the regmap core which I would like to get in through the networking subsystem, if possible (and if Mark is ok), since it's a trivial addition. Maxim Kochetkov (4): soc/mscc: ocelot: add MII registers description net: mscc: ocelot: convert SYS_PAUSE_CFG register access to regfield net: mscc: ocelot: extend watermark encoding function net: dsa: ocelot: introduce driver for Seville VSC9953 switch Vladimir Oltean (7): regmap: add helper for per-port regfield initialization net: mscc: ocelot: unexport ocelot_probe_port net: mscc: ocelot: convert port registers to regmap net: mscc: ocelot: convert QSYS_SWITCH_PORT_MODE and SYS_PORT_MODE to regfields net: dsa: ocelot: create a template for the DSA tags on xmit net: mscc: ocelot: split writes to pause frame enable bit and to thresholds net: mscc: ocelot: disable flow control on NPI interface drivers/net/dsa/ocelot/Kconfig | 12 + drivers/net/dsa/ocelot/Makefile | 6 + drivers/net/dsa/ocelot/felix.c | 49 +- drivers/net/dsa/ocelot/felix_vsc9959.c | 72 +- drivers/net/dsa/ocelot/seville.c | 742 +++++++++++++++ drivers/net/dsa/ocelot/seville.h | 50 + drivers/net/dsa/ocelot/seville_vsc9953.c | 1064 ++++++++++++++++++++++ drivers/net/ethernet/mscc/ocelot.c | 87 +- drivers/net/ethernet/mscc/ocelot.h | 9 +- drivers/net/ethernet/mscc/ocelot_board.c | 21 +- drivers/net/ethernet/mscc/ocelot_io.c | 18 +- drivers/net/ethernet/mscc/ocelot_regs.c | 57 ++ include/linux/regmap.h | 8 + include/soc/mscc/ocelot.h | 68 +- include/soc/mscc/ocelot_dev.h | 78 -- include/soc/mscc/ocelot_qsys.h | 13 - include/soc/mscc/ocelot_sys.h | 23 - net/dsa/tag_ocelot.c | 21 +- 18 files changed, 2196 insertions(+), 202 deletions(-) create mode 100644 drivers/net/dsa/ocelot/seville.c create mode 100644 drivers/net/dsa/ocelot/seville.h create mode 100644 drivers/net/dsa/ocelot/seville_vsc9953.c base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136 -- 2.25.1
2020-05-29regmap: provide helpers for simple bit operationsBartosz Golaszewski1-0/+36
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-29regmap: add helper for per-port regfield initializationVladimir Oltean1-0/+8
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-04-20regmap: Simplify implementation of the regmap_field_read_poll_timeout() macroDejin Zheng1-19/+4
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-20regmap: Simplify implementation of the regmap_read_poll_timeout() macroDejin Zheng1-20/+5
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-14Merge series "Add support for Kontron sl28cpld" from Michael Walle ↵Mark Brown1-0/+10
<michael@walle.cc>: The Kontron sl28cpld is a board management chip providing gpio, pwm, fan monitoring and an interrupt controller. For now this controller is used on the Kontron SMARC-sAL28 board. But because of its flexible nature, it might also be used on other boards in the future. The individual blocks (like gpio, pwm, etc) are kept intentionally small. The MFD core driver then instantiates different (or multiple of the same) blocks. It also provides the register layout so it might be updated in the future without a device tree change; and support other boards with a different layout or functionalities. See also [1] for more information. This is my first take of a MFD driver. I don't know whether the subsystem maintainers should only be CCed on the patches which affect the subsystem or on all patches for this series. I've chosen the latter so you can get a more complete picture. [1] https://lore.kernel.org/linux-devicetree/0e3e8204ab992d75aa07fc36af7e4ab2@walle.cc/ Changes since v1: - use of_match_table in all drivers, needed for automatic module loading, when using OF_MFD_CELL() - add new gpio-regmap.c which adds a generic regmap gpio_chip implemention - new patch for reqmap_irq, so we can reuse its implementation - remove almost any code from gpio-sl28cpld.c, instead use gpio-regmap and regmap-irq - change the handling of the mfd core vs device tree nodes; add a new property "of_reg" to the mfd_cell struct which, when set, is matched to the unit-address of the device tree nodes. - fix sl28cpld watchdog when it is not initialized by the bootloader. Explicitly set the operation mode. - also add support for kontron,assert-wdt-timeout-pin in sl28cpld-wdt. As suggested by Bartosz Golaszewski: - define registers as hex - make gpio enum uppercase - move parent regmap check before memory allocation - use device_property_read_bool() instead of the of_ version - mention the gpio flavors in the bindings documentation As suggested by Guenter Roeck: - cleanup #includes and sort them - use devm_watchdog_register_device() - use watchdog_stop_on_reboot() - provide a Documentation/hwmon/sl28cpld.rst - cleaned up the weird tristate->bool and I2C=y issue. Instead mention that the MFD driver is bool because of the following intc patch - removed the SL28CPLD_IRQ typo As suggested by Rob Herring: - combine all dt bindings docs into one patch - change the node name for all gpio flavors to "gpio" - removed the interrupts-extended rule - cleaned up the unit-address space, see above Michael Walle (16): include/linux/ioport.h: add helper to define REG resource constructs mfd: mfd-core: Don't overwrite the dma_mask of the child device mfd: mfd-core: match device tree node against reg property regmap-irq: make it possible to add irq_chip do a specific device node dt-bindings: mfd: Add bindings for sl28cpld mfd: Add support for Kontron sl28cpld management controller irqchip: add sl28cpld interrupt controller support watchdog: add support for sl28cpld watchdog pwm: add support for sl28cpld PWM controller gpio: add a reusable generic gpio_chip using regmap gpio: add support for the sl28cpld GPIO controller hwmon: add support for the sl28cpld hardware monitoring controller arm64: dts: freescale: sl28: enable sl28cpld arm64: dts: freescale: sl28: map GPIOs to input events arm64: dts: freescale: sl28: enable LED support arm64: dts: freescale: sl28: enable fan support .../bindings/gpio/kontron,sl28cpld-gpio.yaml | 51 +++ .../hwmon/kontron,sl28cpld-hwmon.yaml | 27 ++ .../bindings/mfd/kontron,sl28cpld.yaml | 162 +++++++++ .../bindings/pwm/kontron,sl28cpld-pwm.yaml | 35 ++ .../watchdog/kontron,sl28cpld-wdt.yaml | 35 ++ Documentation/hwmon/sl28cpld.rst | 36 ++ .../fsl-ls1028a-kontron-kbox-a-230-ls.dts | 14 + .../fsl-ls1028a-kontron-sl28-var3-ads2.dts | 9 + .../freescale/fsl-ls1028a-kontron-sl28.dts | 124 +++++++ drivers/base/regmap/regmap-irq.c | 84 ++++- drivers/gpio/Kconfig | 15 + drivers/gpio/Makefile | 2 + drivers/gpio/gpio-regmap.c | 321 ++++++++++++++++++ drivers/gpio/gpio-sl28cpld.c | 187 ++++++++++ drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile | 1 + drivers/hwmon/sl28cpld-hwmon.c | 152 +++++++++ drivers/irqchip/Kconfig | 3 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-sl28cpld.c | 99 ++++++ drivers/mfd/Kconfig | 21 ++ drivers/mfd/Makefile | 2 + drivers/mfd/mfd-core.c | 31 +- drivers/mfd/sl28cpld.c | 154 +++++++++ drivers/pwm/Kconfig | 10 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sl28cpld.c | 204 +++++++++++ drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/sl28cpld_wdt.c | 242 +++++++++++++ include/linux/gpio-regmap.h | 88 +++++ include/linux/ioport.h | 5 + include/linux/mfd/core.h | 26 +- include/linux/regmap.h | 10 + 34 files changed, 2142 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml create mode 100644 Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml create mode 100644 Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml create mode 100644 Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml create mode 100644 Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml create mode 100644 Documentation/hwmon/sl28cpld.rst create mode 100644 drivers/gpio/gpio-regmap.c create mode 100644 drivers/gpio/gpio-sl28cpld.c create mode 100644 drivers/hwmon/sl28cpld-hwmon.c create mode 100644 drivers/irqchip/irq-sl28cpld.c create mode 100644 drivers/mfd/sl28cpld.c create mode 100644 drivers/pwm/pwm-sl28cpld.c create mode 100644 drivers/watchdog/sl28cpld_wdt.c create mode 100644 include/linux/gpio-regmap.h -- 2.20.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-04-14regmap: add reg_sequence helpersMarco Felsch1-0/+7
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 18:39:19 +0000