user/sven/linux.git/include/linux/regmap.h, branch v5.13.16

regmap-irq: Add driver callback to configure virtual regs

2021-03-31T12:53:38Z

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 Link: https://lore.kernel.org/r/07e058cdec2297d15c95c825aa0263064d962d5a.1616613838.git.gurus@codeaurora.org Signed-off-by: Mark Brown

regmap-irq: Introduce virtual regs to handle more config regs

2021-03-31T12:53:37Z

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 Link: https://lore.kernel.org/r/a1787067004b0e11cb960319082764397469215a.1616613838.git.gurus@codeaurora.org Signed-off-by: Mark Brown

regmap-irq: Extend sub-irq to support non-fixed reg strides

2021-03-18T13:55:33Z

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 Link: https://lore.kernel.org/r/526562423eaa58b4075362083f561841f1d6956c.1615423027.git.gurus@codeaurora.org Signed-off-by: Mark Brown

Merge series "regmap/SoundWire/ASoC: Add SoundWire SDCA support" from Bard Liao :

2020-11-26T20:03:02Z

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

regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ

2020-11-26T13:19:59Z

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 Reviewed-by: Guennadi Liakhovetski Reviewed-by: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20201103172226.4278-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown

regmap: mmio: add config option to allow relaxed MMIO accesses

2020-10-26T19:54:59Z

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 Signed-off-by: Adrian Ratiu Link: https://lore.kernel.org/r/20201014203024.954369-1-adrian.ratiu@collabora.com Signed-off-by: Mark Brown

regmap: irq: Add support to clear ack registers

2020-10-05T17:35:30Z

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 Link: https://lore.kernel.org/r/1601907440-13373-1-git-send-email-lkasam@codeaurora.org Signed-off-by: Mark Brown

Merge tag 'regmap-field-bulk-api' into regmap-5.10

2020-09-28T19:50:47Z

regmap: Add a bulk field API Useful for devices with many fields.

regmap: add support to regmap_field_bulk_alloc/free apis

2020-09-28T19:50:03Z

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 Tested-by: Srinivasa Rao Mandadapu Link: https://lore.kernel.org/r/20200925164856.10315-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown

regmap: Add can_sleep configuration option

2020-09-02T18:53:27Z

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 Fixes: 2b32d2f7ce0a ("regmap: Use flexible sleep") Signed-off-by: Dmitry Osipenko Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20200902141843.6591-1-digetx@gmail.com Signed-off-by: Mark Brown