-
Notifications
You must be signed in to change notification settings - Fork 349
intel: ssp: drain RX fifo when starting #7577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@plbossart @ujfalusi I also tried option to disable RSRE (Receive Service Request Enable) when stopping capture, but I could not get this to work. Then I found Pierre your commit "intel: ssp: handle TSRE and RSRE along with SSE" 441b438 . That states RSRE should be set before SSE and if we followed that, we can't really disable RSRE when capture is stopped but playback continues. So that leaves us with the current fix in this PR. |
|
FYI @bardliao who worked on this area with the ES_BCLK feature. |
9a9c23d to
79b31b0
Compare
If DMA is active, do not read data directly from the SSP RX fifo. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
If DMA transaction is ongoing when RX is enabled, this can lead to stuck communication between DMA and SSP (DMA service request not seen by the DMA). To avoid this, flush the RX fifo before enabling SSP RX. Link: thesofproject#7548 Suggested-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
79b31b0 to
d52796e
Compare
| uint64_t sample_ticks = clock_ticks_per_sample(PLATFORM_DEFAULT_CLOCK, | ||
| ssp->params.fsync_rate); | ||
| uint32_t retry = SSP_RX_FLUSH_RETRY_MAX; | ||
| bool direct_reads = ssp->state[DAI_DIR_CAPTURE] <= COMP_STATE_PREPARE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about COMP_STATE_PAUSED? it is not active, and seems will not read with this state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@btian1 That's a good question. Earlier version of the patch broke PAUSE, so I did spend some time looking at this. Curiously, ssp_pause does not stop the hardware and it based on tests, this is not needed after pause. I can't fully explain why this is the case (and DMA is stopped on pause).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the other patch fixes the pause by yanking the FIFO before resume (which is a start operation), it is really strange to be honest, but w/o the FIFO drain patch I had broken pause/resume and I think @kv2019i had a working one on his (identical) setup.
|
Failing CI checks do not test the configuration this PR changes. Proceeding with merge. Thanks to all reviewers! |
Mainline version of #7564
Link: #7548