soundwire: stream: Prepare ports in parallel to reduce stream start l… #5613
Conversation
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
…atency Issue DP prepare to all ports that use full CP_SM. Then wait for the prepare to complete. This allow all the DP to prepare in parallel to reduce the latency of starting an audio stream. On a system with six CS35L56 amps, this reduces the startup latency, from runtime_resume to all amps ready to play, from ~160 ms to ~60 ms. (Test hardware: UpXtreme i14, BIOS v1.2, Core Ultra 7 155H, 3x CS35L56 on link 0, 3x CS35L56 on link 1). An initial read of DPn_PREPARESTATUS is done before dropping into the wait, so that a quick exit can be made if the port is already prepared. Currently this is essential because the wait deadlocks - the stream setup takes bus_lock, which blocks the interrupt handler - so the wait for completion will always timeout. However, an experiment of removing the bus_lock from stream setup, so that the interrupt will work, shows that wait for completion takes ~700..800 us but the quick-exit read takes 50..200 us. So the quick exit is still valuable even if the stream.c code was rewritten to allow the completion interrupt to work. Rewriting the code so it doesn't take bus_lock is risky. The deadlock only lasts until the wait times out so it's not a serious problem now that the DP prepare happens in parallel. Signed-off-by: Richard Fitzgerald <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
…atency
Issue DP prepare to all ports that use full CP_SM. Then wait for the prepare to complete. This allow all the DP to prepare in parallel to reduce the latency of starting an audio stream.
On a system with six CS35L56 amps, this reduces the startup latency, from runtime_resume to all amps ready to play, from ~160 ms to ~60 ms.
(Test hardware: UpXtreme i14, BIOS v1.2, Core Ultra 7 155H, 3x CS35L56 on link 0, 3x CS35L56 on link 1).
An initial read of DPn_PREPARESTATUS is done before dropping into the wait, so that a quick exit can be made if the port is already prepared. Currently this is essential because the wait deadlocks - the stream setup takes bus_lock, which blocks the interrupt handler - so the wait for completion will always timeout.
However, an experiment of removing the bus_lock from stream setup, so that the interrupt will work, shows that wait for completion takes ~700..800 us but the quick-exit read takes 50..200 us. So the quick exit is still valuable even if the stream.c code was rewritten to allow the completion interrupt to work. Rewriting the code so it doesn't take bus_lock is risky. The deadlock only lasts until the wait times out so it's not a serious problem now that the DP prepare happens in parallel.