Repository navigation
Conversation
The compute_params callback is called from both stream prepare and deprepare. A followup commit will make it perform different actions depending on which operation invokes it. No functional change. Signed-off-by: Bard Liao <[email protected]>
When multiple master runtimes exist on the same bus, sdw_compute_bus_params() selects the first runtime for which an additional lane is available. This can select an already running stream instead of the stream being prepared. Changing that runtime's port lanes accounts for its bandwidth again. If preparing the new stream fails, restoring the bus parameters leaves the active stream's lanes inconsistent with its bandwidth reservation. Depreparing the active stream can then underflow the lane bandwidth and leave lane 0 bandwidth reserved. Pass the current stream and prepare context to sdw_compute_bus_params() and restrict lane allocation to that stream's runtime during prepare. Skip lane allocation during deprepare, when its bandwidth reservation has already been released. Keep clock recomputation and the existing group and port filtering unchanged. Signed-off-by: Bard Liao <[email protected]>
sdw_prepare_stream() accepts a stream in the DEPREPARED state without changing its state before parameter computation. However, the generic allocator excludes DEPREPARED streams from rate groups and port computation, and only includes a CONFIGURED current stream in group payload calculations. Consequently, preparing an existing stream again can reserve bandwidth without computing the corresponding transport parameters. The filters need to distinguish preparing that stream again from depreparing it. Pass the prepare context through the group and port helpers. Include the current stream during prepare even when it is still DEPREPARED, while preserving the filtering of all other runtimes and the behavior during deprepare. This supports preparing again without temporarily changing stream state. Signed-off-by: Bard Liao <[email protected]>
…n failure A failed prepare restores the bus parameters but leaves the master and peripheral port lane assignments unchanged. If a subsequent prepare selects lane 0, the existing nonzero-lane-only assignment path leaves the ports using the stale lanes from the failed attempt. Rather than saving and restoring the original port lanes on failure, apply the newly computed lane assignments on each successful bus parameter calculation during prepare. Explicitly clear the current stream's master and peripheral port lanes when lane 0 is selected; the existing path already updates them when a nonzero lane is selected. This ensures that a subsequent prepare uses the newly selected lanes, including when retrying with the same port runtimes, instead of relying on the lane values left by the failed attempt. Lane assignments are not changed during deprepare. Signed-off-by: Bard Liao <[email protected]>
bardliao
requested review from
davidlin923,
plbossart and
ujfalusi
and
a balanced review from Copilot
November 3, 2026 14:32
bardliao
requested review from
jack-cy-yu,
oder-chiou and
shumingfan
as code owners
November 3, 2026 14:32
There was a problem hiding this comment.
🟢 Approval recommended
The SoundWire bandwidth-allocation changes have no active review issues blocking approval.
No open issues 🎉
What changed in this PR
This follow-up refines SoundWire bandwidth allocation for multi-link failure handling by explicitly distinguishing stream preparation from depreparation.
Changes:
- Add a
prepareflag to the bandwidth-computation interface and update callers and controller callbacks. - Include the current stream in preparation calculations even when its state is still
DEPREPARED. - Limit lane selection to the stream being prepared and clear stale lane assignments when preparing on lane 0.
| File | Description |
|---|---|
include/linux/soundwire/sdw.h |
Extend and document the computation interface with the prepare flag. |
drivers/soundwire/stream.c |
Pass the appropriate flag during preparation and depreparation. |
drivers/soundwire/qcom.c |
Update the Qualcomm callback signature to match the interface. |
drivers/soundwire/generic_bandwidth_allocation.c |
Adjust stream inclusion and lane assignment using explicit preparation context. |
drivers/soundwire/amd_manager.c |
Update the AMD callback signature to match the interface. |
Review effort: Balanced
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To address review comments form [email protected]
https://sashiko.dev/#/patchset/[email protected]?part=2