Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
154cfc3d |
| 17-Oct-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: bus: introduce controller_id
[ Upstream commit 6543ac13c623f906200dfd3f1c407d8d333b6995 ]
The existing SoundWire support misses a clear Controller/Manager hiearchical definition to deal
soundwire: bus: introduce controller_id
[ 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 <yung-chuan.liao@linux.intel.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/stable/20231017160933.12624-2-pierre-louis.bossart%40linux.intel.com Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231017160933.12624-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Stable-dep-of: 8a8a9ac8a497 ("soundwire: fix initializing sysfs for same devices on different buses") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.5.7, v6.5.6, v6.5.5 |
|
#
3b6c4a11 |
| 20-Sep-2023 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
soundwire: bus: Make IRQ handling conditionally built
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 hand
soundwire: bus: Make IRQ handling conditionally built
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 <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309150522.MoKeF4jx-lkp@intel.com/ Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230920160401.854052-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44 |
|
#
12a95123 |
| 04-Aug-2023 |
Lucas Tanure <tanureal@opensource.cirrus.com> |
soundwire: bus: Allow SoundWire peripherals to register IRQ handlers
Currently the in-band alerts for SoundWire peripherals can only be communicated to the driver through the interrupt_callback func
soundwire: bus: Allow SoundWire peripherals to register IRQ handlers
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 <tanureal@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Bard Liao <yung-chuan.liao@linux.intel.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230804104602.395892-2-ckeepax@opensource.cirrus.com Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
Revision tags: v6.1.43 |
|
#
39d80b0e |
| 31-Jul-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: bus: add callbacks for device_number allocation
Rather than add logic in the core for vendor-specific usages, add callbacks for vendor-specific device_number allocation and release.
This
soundwire: bus: add callbacks for device_number allocation
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 <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230731091333.3593132-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
23afc82f |
| 31-Jul-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: extend parameters of new_peripheral_assigned() callback
The parameters are only the bus and the device number, manager ops may need additional details on the type of peripheral connected,
soundwire: extend parameters of new_peripheral_assigned() callback
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 <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230731091333.3593132-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38 |
|
#
c40d6b32 |
| 05-Jul-2023 |
Johan Hovold <johan+linaro@kernel.org> |
soundwire: fix enumeration completion
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
soundwire: fix enumeration completion
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 <pierre-louis.bossart@linux.intel.com> Cc: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230705123018.30903-2-johan+linaro@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
256a9978 |
| 15-Jun-2023 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Prevent lockdep asserts when stream has multiple buses
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
soundwire: bus: Prevent lockdep asserts when stream has multiple buses
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 <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230615141208.679011-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29 |
|
#
6bac0d8d |
| 15-May-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: bus: add new manager callback to deal with peripheral enumeration
When a peripheral reports as ATTACHED, the manager may need to follow a programming sequence, e.g. to assign DMA resource
soundwire: bus: add new manager callback to deal with peripheral enumeration
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 <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230515071042.2038-20-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
9420c971 |
| 18-Apr-2023 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
soundwire: bus: Don't filter slave alerts
It makes sense to have only a single point responsible for ensuring that all currently pending IRQs are handled. The current code in sdw_handle_slave_alerts
soundwire: bus: Don't filter slave alerts
It makes sense to have only a single point responsible for ensuring that all currently pending IRQs are handled. The current code in sdw_handle_slave_alerts confusingly splits this process in two. This code will loop until the asserted IRQs are cleared but it will only handle IRQs that were already asserted when it was called. This means the caller must also loop (either manually, or through its IRQ mechanism) until the IRQs are all handled. It makes sense to either do all the looping in sdw_handle_slave_alerts or do no looping there and let the host controller repeatedly call it until things are handled.
There are realistically two sensible host controllers, those that will generate an IRQ when the alert status changes and those that will generate an IRQ continuously whilst the alert status is high. The current code will work fine for the second of those systems but not the first with out additional looping in the host controller. Removing the code that filters out new IRQs whilst the handler is running enables both types of host controller to be supported and simplifies the code. The code will still only loop up to SDW_READ_INTR_CLEAR_RETRY times, so it shouldn't be possible for it to get completely stuck handling IRQs forever, and if you are generating IRQs faster than you can handle them you likely have bigger problems anyway.
This fixes an issue on the Cadence SoundWire IP, which only generates IRQs on an alert status change, where an alert which arrives whilst another alert is being handled will never be handled and will block all future alerts from being handled.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230418140650.297279-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.24 |
|
#
e9537962 |
| 06-Apr-2023 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow
This reverts commit 443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")
Change calls to pm_runtime_resume_
soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow
This reverts commit 443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")
Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync(). This fixes a usage count underrun caused by doing a pm_runtime_put() even though pm_runtime_resume_and_get() returned an error.
The three affected functions ignore -EACCES error from trying to get pm_runtime, and carry on, including a put at the end of the function. But pm_runtime_resume_and_get() does not increment the usage count if it returns an error. So in the -EACCES case you must not call pm_runtime_put().
The documentation for pm_runtime_get_sync() says: "Consider using pm_runtime_resume_and_get() ... as this is likely to result in cleaner code."
In this case I don't think it results in cleaner code because the pm_runtime_put() at the end of the function would have to be conditional on the return value from pm_runtime_resume_and_get() at the top of the function.
pm_runtime_get_sync() doesn't have this problem because it always increments the count, so always needs a put. The code can just flow through and do the pm_runtime_put() unconditionally.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230406134640.8582-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.23, v6.1.22 |
|
#
d005ea71 |
| 22-Mar-2023 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
soundwire: bus: Update sdw_nread/nwrite_no_pm to handle page boundaries
Currently issuing a sdw_nread/nwrite_no_pm across a page boundary will silently fail to write correctly as nothing updates the
soundwire: bus: Update sdw_nread/nwrite_no_pm to handle page boundaries
Currently issuing a sdw_nread/nwrite_no_pm across a page boundary will silently fail to write correctly as nothing updates the page registers, meaning the same page of the chip will get rewritten with each successive page of data.
As the sdw_msg structure contains page information it seems reasonable that a single sdw_msg should always be within one page. It is also mostly simpler to handle the paging at the bus level rather than each master having to handle it in their xfer_msg callback.
As such add handling to the bus code to split up a transfer into multiple sdw_msg's when they go across page boundaries.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230322164948.566962-3-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
d94e1e01 |
| 22-Mar-2023 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
soundwire: bus: Update kernel doc for no_pm functions
The kernel doc should really have been updated when the no_pm versions of the sdw_write/read functions were exported in commits:
commit 167790a
soundwire: bus: Update kernel doc for no_pm functions
The kernel doc should really have been updated when the no_pm versions of the sdw_write/read functions were exported in commits:
commit 167790abb90f ("soundwire: export sdw_write/read_no_pm functions") commit 62dc9f3f2fd0 ("soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions")
Add the missing kernel doc.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230322164948.566962-2-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
ff9608c3 |
| 22-Mar-2023 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
soundwire: bus: Remove now outdated comments on no_pm IO
Things have moved more towards end drivers using the no_pm versions of the IO functions. See commits:
commit 167790abb90f ("soundwire: expor
soundwire: bus: Remove now outdated comments on no_pm IO
Things have moved more towards end drivers using the no_pm versions of the IO functions. See commits:
commit 167790abb90f ("soundwire: export sdw_write/read_no_pm functions") commit 62dc9f3f2fd0 ("soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions")
As such this comment is now misleading, so remove it.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230322164948.566962-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8 |
|
#
66f95de7 |
| 19-Jan-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: cadence: further simplify low-level xfer_msg_defer() callback
The message pointer is already stored in the bus->defer structure, not need to pass it as an argument.
Suggested-by: Ranjani
soundwire: cadence: further simplify low-level xfer_msg_defer() callback
The message pointer is already stored in the bus->defer structure, not need to pass it as an argument.
Suggested-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
dd0b9619 |
| 19-Jan-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: cadence: use directly bus sdw_defer structure
Copying the bus sdw_defer structure into the Cadence internals leads to using stale pointers and kernel oopses on errors. It's just simpler a
soundwire: cadence: use directly bus sdw_defer structure
Copying the bus sdw_defer structure into the Cadence internals leads to using stale pointers and kernel oopses on errors. It's just simpler and safer to use the bus sdw_defer structure directly.
Link: https://github.com/thesofproject/linux/issues/4056 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
45cb70f9 |
| 19-Jan-2023 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: bus: remove sdw_defer argument in sdw_transfer_defer()
There's no point in passing an argument that is a pointer to a bus member. We can directly get the member and do an indirection when
soundwire: bus: remove sdw_defer argument in sdw_transfer_defer()
There's no point in passing an argument that is a pointer to a bus member. We can directly get the member and do an indirection when needed.
This is a first step before simplifying the hardware-specific callbacks further.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
c8a0d6b2 |
| 23-Jan-2023 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Don't zero page registers after every transaction
Zeroing the page registers at the end of every paged transaction is just overhead (40% overhead on a 1-register access, 25% on a 4-r
soundwire: bus: Don't zero page registers after every transaction
Zeroing the page registers at the end of every paged transaction is just overhead (40% overhead on a 1-register access, 25% on a 4-register transaction). According to the spec a peripheral that supports paging should only use the values in the page registers if the address is paged (address bit 15 set). The core SoundWire code always writes the page registers at the start of a paged transaction so there will never be a transaction that uses the stale values from a previous paged transaction.
For peripherals that need large amounts of data to be transferred, for example firmware or filter coefficients, the overhead of page register zeroing can become quite significant.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230123164949.245898-2-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80 |
|
#
545c3651 |
| 25-Nov-2022 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
soundwire: stream: Move remaining register accesses over to no_pm
There is no need to play with the runtime reference everytime a register is accessed. All the remaining "pm" style register accesses
soundwire: stream: Move remaining register accesses over to no_pm
There is no need to play with the runtime reference everytime a register is accessed. All the remaining "pm" style register accesses trace back to 4 functions:
sdw_prepare_stream sdw_deprepare_stream sdw_enable_stream sdw_disable_stream
Any sensible implementation will need to hold a runtime reference across all those functions, it makes no sense to be allowing the device/bus to suspend whilst streams are being prepared/enabled. And certainly in the case of the all existing users, they all call these functions from hw_params/prepare/trigger/hw_free callbacks in ALSA, which will have already runtime resumed all the audio devices associated during the open callback.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221125142028.1118618-5-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
62dc9f3f |
| 25-Nov-2022 |
Simon Trimmer <simont@opensource.cirrus.com> |
soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions
The commit 167790abb90f ("soundwire: export sdw_write/read_no_pm functions") exposed the single byte no_pm versions of the IO fu
soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions
The commit 167790abb90f ("soundwire: export sdw_write/read_no_pm functions") exposed the single byte no_pm versions of the IO functions that can be used without touching PM, export the multi byte no_pm versions for the same reason.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221125142028.1118618-2-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
ffa17265 |
| 17-Nov-2022 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
soundwire: enable optional clock registers for SoundWire 1.2 devices
The bus supports the mandatory clock registers for SDCA devices, these registers can also be optionally supported by SoundWire 1.
soundwire: enable optional clock registers for SoundWire 1.2 devices
The bus supports the mandatory clock registers for SDCA devices, these registers can also be optionally supported by SoundWire 1.2 devices that don't follow the SDCA class specification.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221118025807.534863-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
be505ba8 |
| 17-Nov-2022 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
ASoC/soundwire: remove is_sdca boolean property
The Device_ID registers already tell us if a device supports the SDCA specification or not, in hindsight we never needed a property when the informati
ASoC/soundwire: remove is_sdca boolean property
The Device_ID registers already tell us if a device supports the SDCA specification or not, in hindsight we never needed a property when the information is reported by both hardware and ACPI.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221118025807.534863-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69 |
|
#
560458df |
| 17-Sep-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Fix wrong port number in sdw_handle_slave_alerts()
for_each_set_bit() gives the bit-number counting from 0 (LSbit==0). When processing INTSTAT2, bit 0 is DP4 so the port number is (b
soundwire: bus: Fix wrong port number in sdw_handle_slave_alerts()
for_each_set_bit() gives the bit-number counting from 0 (LSbit==0). When processing INTSTAT2, bit 0 is DP4 so the port number is (bit + 4). Likewise for INTSTAT3 bit 0 is DP11 so port number is (bit + 11).
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220917140256.689678-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
Revision tags: v5.15.68 |
|
#
72124f07 |
| 14-Sep-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Don't exit early if no device IDs were programmed
Only exit sdw_handle_slave_status() right after calling sdw_program_device_num() if it actually programmed an ID into at least one d
soundwire: bus: Don't exit early if no device IDs were programmed
Only exit sdw_handle_slave_status() right after calling sdw_program_device_num() if it actually programmed an ID into at least one device.
sdw_handle_slave_status() should protect itself against phantom device #0 ATTACHED indications. In that case there is no actual device still on #0. The early exit relies on there being a status change to ATTACHED on the reprogrammed device to trigger another call to sdw_handle_slave_status() which will then handle the status of all peripherals. If no device was actually programmed with an ID there won't be a new ATTACHED indication. This can lead to the status of other peripherals not being handled.
The status passed to sdw_handle_slave_status() is obviously always from a point of time in the past, and may indicate accumulated unhandled events (depending how the bus manager operates). It's possible that a device ID is reprogrammed but the last PING status captured state just before that, when it was still reporting on ID #0. Then sdw_handle_slave_status() is called with this PING info, just before a new PING status is available showing it now on its new ID. So sdw_handle_slave_status() will receive a phantom report of a device on #0, but it will not find one.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220914160248.1047627-6-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
7297f8fa |
| 14-Sep-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Don't re-enumerate before status is UNATTACHED
Don't re-enumerate a peripheral on #0 until we have seen and handled an UNATTACHED notification for that peripheral.
Without this, it
soundwire: bus: Don't re-enumerate before status is UNATTACHED
Don't re-enumerate a peripheral on #0 until we have seen and handled an UNATTACHED notification for that peripheral.
Without this, it is possible for the UNATTACHED status to be missed and so the slave->status remains at ATTACHED. If slave->status never changes to UNATTACHED the child driver will never be notified of the UNATTACH, and the code in sdw_handle_slave_status() will skip the second part of enumeration because the slave->status has not changed.
This scenario can happen because PINGs are handled in a workqueue function which is working from a snapshot of an old PING, and there is no guarantee when this function will run.
A peripheral could report attached in the PING being handled by sdw_handle_slave_status(), but has since reverted to device #0 and is then found in the loop in sdw_program_device_num(). Previously the code would not have updated slave->status to UNATTACHED because it had not yet handled a PING where that peripheral had UNATTACHED.
This situation happens fairly frequently with multiple peripherals on a bus that are intentionally reset (for example after downloading firmware).
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220914160248.1047627-4-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
f605f32e |
| 14-Sep-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
soundwire: bus: Don't lose unattach notifications
Ensure that if sdw_handle_slave_status() sees a peripheral has dropped off the bus it reports it to the client driver.
If there are any devices rep
soundwire: bus: Don't lose unattach notifications
Ensure that if sdw_handle_slave_status() sees a peripheral has dropped off the bus it reports it to the client driver.
If there are any devices reporting on address 0 it bails out after programming the device IDs. So it never reaches the second loop that calls sdw_update_slave_status().
If the missing device is one that is now showing as unenumerated it has been given a device ID so will report as attached next time sdw_handle_slave_status() runs.
With the previous code the client driver would only see another ATTACHED notification because the UNATTACHED state was lost when sdw_handle_slave_status() bailed out after programming the device ID.
This shows up most when the peripheral has to be reset after downloading updated firmware and there are multiple of these peripherals on the bus. They will all return to unenumerated state after the reset, and then there is a mix of unattached, attached and unenumerated PING states from the peripherals, as each is reset and they reboot.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220914160248.1047627-3-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
show more ...
|