linux.git/drivers/soundwire/bus.c, branch v6.6.83

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

soundwire: bus: Make IRQ handling conditionally built

2023-09-21T09:31:33+00:00

SoundWire has provisions for a simple callback for the IRQ handling so
has no hard dependency on IRQ_DOMAIN, but the recent addition of IRQ
handling was causing builds without IRQ_DOMAIN to fail. Resolve this by
moving the IRQ handling into its own file and only add it to the build
when IRQ_DOMAIN is included in the kernel.

Fixes: 12a95123bfe1 ("soundwire: bus: Allow SoundWire peripherals to register IRQ handlers")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202309150522.MoKeF4jx-lkp@intel.com/
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20230920160401.854052-1-ckeepax@opensource.cirrus.com
Signed-off-by: Vinod Koul

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

mfd: Immutable branch between MFD, Pinctrl and soundwire due for the v6.6 merge window

2023-08-18T16:37:08+00:00

Merge tag 'ib-mfd-pinctrl-soundwire-v6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into tmp

Immutable branch between MFD, Pinctrl and soundwire due for the v6.6 merge window

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: 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

soundwire: fix enumeration completion

2023-07-12T17:00:15+00:00

The soundwire subsystem uses two completion structures that allow
drivers to wait for soundwire device to become enumerated on the bus and
initialised by their drivers, respectively.

The code implementing the signalling is currently broken as it does not
signal all current and future waiters and also uses the wrong
reinitialisation function, which can potentially lead to memory
corruption if there are still waiters on the queue.

Not signalling future waiters specifically breaks sound card probe
deferrals as codec drivers can not tell that the soundwire device is
already attached when being reprobed. Some codec runtime PM
implementations suffer from similar problems as waiting for enumeration
during resume can also timeout despite the device already having been
enumerated.

Fixes: fb9469e54fa7 ("soundwire: bus: fix race condition with enumeration_complete signaling")
Fixes: a90def068127 ("soundwire: bus: fix race condition with initialization_complete signaling")
Cc: stable@vger.kernel.org      # 5.7
Cc: Pierre-Louis Bossart 
Cc: Rander Wang 
Signed-off-by: Johan Hovold 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20230705123018.30903-2-johan+linaro@kernel.org
Signed-off-by: Vinod Koul

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: bus: add new manager callback to deal with peripheral enumeration

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

When a peripheral reports as ATTACHED, the manager may need to follow
a programming sequence, e.g. to assign DMA resources and/or assign a
command queue for that peripheral.

This patch adds an optional callback, which will be invoked every time
the peripheral attaches. This might be overkill in some scenarios, and
one could argue that this should be invoked only on the first
attachment. The bus does not however track this first attachment with
any existing state-mirroring variable, and using dev_num_sticky would
not work across suspend-resume cycles.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Ranjani Sridharan 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230515071042.2038-20-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul