-
Notifications
You must be signed in to change notification settings - Fork 140
Chain dma support #3953
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
Chain dma support #3953
Conversation
|
Could you give a full picture of solution ? How to use chain dma ? How to support in topology ? How does driver do to cooperate with topology? |
|
@jsarha can you please squash the relevant patches and add descriptions? It is very hard to review it like this. Also, IPC4 test fails spectacularly. So something is not right. |
|
Here is the squashed up version, but there is still something severely wrong with normal playback, and I am in the middle of debugging it. |
plbossart
left a comment
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.
This is encouraging @jsarha, this PR needs more comments, background information and needs a bit of polishing.
I think we should really try the capture as well, this could be really really useful to hardware validation. In the end we would have
a) DSP-less
b) chained DMA
c) full firmware support with decoupled DMAs.
ujfalusi
left a comment
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.
@jsarha, this looks really good, few additional nit-picks, I can not see anything else apart from what has been asked.
|
All the issues found in the review are not yet addressed, but pushed the branch again to trigger CI tests to see if the nocodec problems persist. |
|
I don't understand why details links lead to 404. Maybe another push will help. There is some more fixes this time too. I think this is the last unresolved issue: #3953 (comment) |
01.org is down. Can you check the internal link @jsarha |
| ret = sof_set_widget_pipeline(sdev, spipe, swidget); | ||
| if (ret < 0) | ||
| return ret; | ||
| if (widget_ops[swidget->id].ipc_setup) { |
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.
add white space line before "if (widget_ops[swidget->id].ipc_setup) {"
|
Hmm. Just setting node_id to invalid does not appear to be enough: Nov 30 09:09:17 jhary kernel: divide error: 0000 [#1] PREEMPT SMP NOPTI |
|
I do not see a single division in snd_soc_pcm_component_delay(), so where does the "divide error" come from? |
|
... one more time. @ujfalusi , @ranj063 , @plbossart , and @RanderWang , please review again. |
|
|
@jsarha please skip the first commit since there is a fixup, thanks |
ujfalusi
left a comment
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.
@jsarha, looks good, one nitpcik of mine is the setting of bools in one line in sof_ipc4_chain_dma_trigger(), but nothing else.
Set up the IPC structure for scheduler widgets and set the pipeline widget before updating the IPC structures for all widgets. This will be needed to look up pipeline information during IPC structure set up. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Jyri Sarha <jyri.sarha@intel.com>
In the chained DMA mode, the firmware allocates buffers for the host and link DMA, and takes care of copying data between host- and link-DMA buffers in a low-latency thread. This is different to a regular pipeline, no processing is allowed, and the connection between host- and link DMA is handled with a dedicated IPC. This patch exposes the macros needed to create the required IPC messages. Signed-off-by: Jyri Sarha <jyri.sarha@intel.com>
Add logic for setting up and tearing down chained DMA connections. Since pipelines are not used, all the logic to set the pipeline states can be bypassed, with only the DMA programming sequences remaining. In addition the same format needs to be used for host- and link-DMA, without the usual fixup to use the S32_LE format on the link. Note however that for convenience and compatibility with existing definitions, the topology relies on the concept of pipelines with a 'USE_CHAIN_DMA' token indicating that all the logic shall be bypassed. Unlike 'normal' ALSA sequences, the chain DMA is not programmed in hw_params/hw_free. The IPC message to set-up and tear-down chained DMA are sent in sof_ipc4_trigger_pipelines(), but the contents prepared earlier. Chained DMA is only supported by the Intel HDA DAI for now, and only S16_LE and S32_LE formats are supported for now. Signed-off-by: Jyri Sarha <jyri.sarha@intel.com>
|
Now that #4050 is merged, there should nothing stopping from approving and merging this too (but I have been wrong many times before 😅) . @ujfalusi , @ranj063 , @plbossart , and @RanderWang , please review again. |
Nice work and thanks for being patient with this one @jsarha. |
|
SOFCI TEST |
ujfalusi
left a comment
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.
@jsarha, thank you for the update, no more nitpicks from my side.
Its probably worth squashing this up a bit, especially now that I had to mangle Ranjani's commit quite a bit when solving sof-dev rebase conflicts. But maybe this is easier to review in pieces.
Both 16- and 32-bit audio works with this PR, but getting 44.1kHz need still some more work.