kernel/linux.git/include/linux/soundwire, branch v6.6.131

soundwire: bus: introduce controller_id

2024-02-01T00:18:47+00:00

[ Upstream commit 6543ac13c623f906200dfd3f1c407d8d333b6995 ] The existing SoundWire support misses a clear Controller/Manager hiearchical definition to deal with all variants across SOC vendors. a) Intel platforms have one controller with 4 or more Managers. b) AMD platforms have two controllers with one Manager each, but due to BIOS issues use two different link_id values within the scope of a single controller. c) QCOM platforms have one or more controller with one Manager each. This patch adds a 'controller_id' which can be set by higher levels. If assigned to -1, the controller_id will be set to the system-unique IDA-assigned bus->id. The main change is that the bus->id is no longer used for any device name, which makes the definition completely predictable and not dependent on any enumeration order. The bus->id is only used to insert the Managers in the stream rt context. Reviewed-by: Bard Liao Reviewed-by: Vijendar Mukunda Signed-off-by: Pierre-Louis Bossart Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/stable/20231017160933.12624-2-pierre-louis.bossart%40linux.intel.com Tested-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20231017160933.12624-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul Stable-dep-of: 8a8a9ac8a497 ("soundwire: fix initializing sysfs for same devices on different buses") Signed-off-by: Sasha Levin

Merge tag 'soundwire-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire

2023-09-03T17:20:57+00:00

Pull soundwire updates from Vinod Koul: "Device numbering and intel driver changes are main features: - Core support for soundwire device number allocation - intel driver updates for adding hw_params for DAI ops, hybrid number allocation and power managemnt callback updates - DT header include changes for subsystem" * tag 'soundwire-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: intel_ace2x: add DAI hw_params/prepare/hw_free callbacks soundwire: intel_auxdevice: add hybrid IDA-based device_number allocation soundwire: bus: add callbacks for device_number allocation soundwire: extend parameters of new_peripheral_assigned() callback soundWire: intel_auxdevice: resume 'sdw-master' on startup and system resume soundwire: intel_auxdevice: enable pm_runtime earlier on startup soundwire: Explicitly include correct DT includes

Add cs42l43 PC focused SoundWire CODEC

2023-08-22T11:48:04+00:00

Merge series from Charles Keepax : This patch chain adds support for the Cirrus Logic cs42l43 PC focused SoundWire CODEC. The chain is currently based of Lee's for-mfd-next branch. This series is mostly just a resend keeping pace with the kernel under it, except for a minor fixup in the ASoC stuff. Thanks, Charles Charles Keepax (4): dt-bindings: mfd: cirrus,cs42l43: Add initial DT binding mfd: cs42l43: Add support for cs42l43 core driver pinctrl: cs42l43: Add support for the cs42l43 ASoC: cs42l43: Add support for the cs42l43 Lucas Tanure (2): soundwire: bus: Allow SoundWire peripherals to register IRQ handlers spi: cs42l43: Add SPI controller support .../bindings/sound/cirrus,cs42l43.yaml | 313 +++ MAINTAINERS | 4 + drivers/mfd/Kconfig | 23 + drivers/mfd/Makefile | 3 + drivers/mfd/cs42l43-i2c.c | 98 + drivers/mfd/cs42l43-sdw.c | 239 ++ drivers/mfd/cs42l43.c | 1188 +++++++++ drivers/mfd/cs42l43.h | 28 + drivers/pinctrl/cirrus/Kconfig | 11 + drivers/pinctrl/cirrus/Makefile | 2 + drivers/pinctrl/cirrus/pinctrl-cs42l43.c | 609 +++++ drivers/soundwire/bus.c | 32 + drivers/soundwire/bus_type.c | 12 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/spi-cs42l43.c | 284 ++ include/linux/mfd/cs42l43-regs.h | 1184 +++++++++ include/linux/mfd/cs42l43.h | 102 + include/linux/soundwire/sdw.h | 9 + include/sound/cs42l43.h | 17 + sound/soc/codecs/Kconfig | 16 + sound/soc/codecs/Makefile | 4 + sound/soc/codecs/cs42l43-jack.c | 946 +++++++ sound/soc/codecs/cs42l43-sdw.c | 74 + sound/soc/codecs/cs42l43.c | 2278 +++++++++++++++++ sound/soc/codecs/cs42l43.h | 131 + 26 files changed, 7615 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml create mode 100644 drivers/mfd/cs42l43-i2c.c create mode 100644 drivers/mfd/cs42l43-sdw.c create mode 100644 drivers/mfd/cs42l43.c create mode 100644 drivers/mfd/cs42l43.h create mode 100644 drivers/pinctrl/cirrus/pinctrl-cs42l43.c create mode 100644 drivers/spi/spi-cs42l43.c create mode 100644 include/linux/mfd/cs42l43-regs.h create mode 100644 include/linux/mfd/cs42l43.h create mode 100644 include/sound/cs42l43.h create mode 100644 sound/soc/codecs/cs42l43-jack.c create mode 100644 sound/soc/codecs/cs42l43-sdw.c create mode 100644 sound/soc/codecs/cs42l43.c create mode 100644 sound/soc/codecs/cs42l43.h -- 2.30.2

soundwire: bus: Allow SoundWire peripherals to register IRQ handlers

2023-08-17T11:06:11+00:00

Currently the in-band alerts for SoundWire peripherals can only be communicated to the driver through the interrupt_callback function. This however is slightly inconvenient for devices that wish to share IRQ handling code between SoundWire and I2C/SPI, the later would normally register an IRQ handler with the IRQ subsystem. However there is no reason the SoundWire in-band IRQs can not also be communicated as an actual IRQ to the driver. Add support for SoundWire peripherals to register a normal IRQ handler to receive SoundWire in-band alerts, allowing code to be shared across control buses. Note that we allow users to use both the interrupt_callback and the IRQ handler, this is useful for devices which must clear additional chip specific SoundWire registers that are not a part of the normal IRQ flow, or the SoundWire specification. Signed-off-by: Lucas Tanure Reviewed-by: Pierre-Louis Bossart Acked-by: Bard Liao Acked-by: Vinod Koul Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20230804104602.395892-2-ckeepax@opensource.cirrus.com Signed-off-by: Lee Jones

soundwire: intel_auxdevice: add hybrid IDA-based device_number allocation

2023-08-11T06:59:25+00:00

The IDA-based allocation is useful to simplify debug, but it was also introduced as a prerequisite to deal with the Intel Lunar Lake hardware programming sequences: the wake-ups have to be handled with a system-unique SDI address at the HDaudio controller level. At the time, the restriction introduced by the IDA to 8 devices total seemed perfectly fine, but recently hardware vendors created configurations with more than 8 devices. Add a new allocation strategy to allow for more than 8 devices using information on the type of devices, and only use the IDA-based allocation for devices capable of generating a wake. In theory the information on wake capabilities should come from firmware, but none of the existing ACPI tables provide it. The drivers set the 'wake_capable' property, but this cannot be used reliably: if the driver probe happens *after* the enumeration, then that property is not initialized yet. Trying to modify the device_number on-the-fly proved to be an impossible task generating race conditions left and right. The only reliable work-around to control the enumeration is to add a quirk table. It's ugly but until platform firmware improves, hopefully as a result of MIPI/SDCA stardization, we can expect that quirk table to grow for each new headset or microphone codec. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230731091333.3593132-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul

soundwire: bus: add callbacks for device_number allocation

2023-08-11T06:59:25+00:00

Rather than add logic in the core for vendor-specific usages, add callbacks for vendor-specific device_number allocation and release. This patch only moves the existing IDA-based allocator used only by Intel to the intel_auxdevice.c file and does not change the functionality. Follow-up patches will extend the behavior by modifying the Intel callbacks. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230731091333.3593132-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul

soundwire: extend parameters of new_peripheral_assigned() callback

2023-08-11T06:59:25+00:00

The parameters are only the bus and the device number, manager ops may need additional details on the type of peripheral connected, such as whether it is wake-capable or not. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230731091333.3593132-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul

ASoC: soc-acpi: move link_slaves_found()

2023-07-31T22:24:00+00:00

Move existing function in common library to make sure the code can be reused by other SoC vendors. No functionality change outside of the move and added prefix. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20230731213242.434594-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

soundwire: bus: Prevent lockdep asserts when stream has multiple buses

2023-06-21T11:01:44+00:00

Give the bus_lock and msg_lock of each bus a different unique key so that it is possible to acquire the locks of multiple buses without lockdep asserting a possible deadlock. Using mutex_init() to initialize a mutex gives all those mutexes the same lock class. Lockdep checking treats it as an error to attempt to take a mutex while already holding a mutex of the same class. This causes a lockdep assert when sdw_acquire_bus_lock() attempts to lock multiple buses, and when do_bank_switch() takes multiple msg_lock. [ 138.697350] WARNING: possible recursive locking detected [ 138.697366] 6.3.0-test #1 Tainted: G E [ 138.697380] -------------------------------------------- [ 138.697394] play/903 is trying to acquire lock: [ 138.697409] ffff99b8c41aa8c8 (&bus->bus_lock){+.+.}-{3:3}, at: sdw_prepare_stream+0x52/0x2e0 [ 138.697443] but task is already holding lock: [ 138.697468] ffff99b8c41af8c8 (&bus->bus_lock){+.+.}-{3:3}, at: sdw_prepare_stream+0x52/0x2e0 [ 138.697493] other info that might help us debug this: [ 138.697521] Possible unsafe locking scenario: [ 138.697540] CPU0 [ 138.697550] ---- [ 138.697559] lock(&bus->bus_lock); [ 138.697570] lock(&bus->bus_lock); [ 138.697581] *** DEADLOCK *** Giving each mutex a unique key allows multiple to be held without triggering a lockdep assert. But note that it does not allow them to be taken in one order then a different order. If two mutexes are taken in the order A, B then they must always be taken in that order otherwise they could deadlock. Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230615141208.679011-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul

soundwire: intel: use substream for .free callback

2023-05-27T10:36:47+00:00

The interface is not needed for IPC3 but will be needed for ACE2.x+IPC4 combinations, with the substream information passed as a parameter. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230515071042.2038-27-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul