-
Notifications
You must be signed in to change notification settings - Fork 140
Enabling SOF Kernel support for AMD Platform #3054
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
|
Can one of the admins verify this patch?
|
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.
Thanks for the patches, very interesting to see SOF being used on a new platform.
I think the first order of business is to clarify the license. It's not my place to tell AMD what the license for the code submitted by AMD should be, but consistency between SPDX and MODULE_LICENSE_INFO is required.
sound/soc/amd/acp/acp-platform.c
Outdated
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.
BSD?
sound/soc/amd/acp/acp-config.c
Outdated
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.
BSD?
sound/soc/sof/amd/pci-rn.c
Outdated
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.
useless inits?
sound/soc/sof/amd/pci-rn.c
Outdated
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.
if (!res) return -ENOMEM?
|
test this please |
|
@ajitkupandey the number of checkpatch issues is rather large, you may want to take a look at https://sof-ci.01.org/linuxpr/PR3054/build6050/checkpatch/ |
sound/soc/amd/acp/acp-config.c
Outdated
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.
unnecessary init
sound/soc/amd/acp/acp-i2s.c
Outdated
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.
missing newline?
sound/soc/sof/amd/acp.c
Outdated
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.
no need to init
sound/soc/sof/amd/acp.c
Outdated
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.
no need for out. just free irq here and return ret at the end
sound/soc/sof/amd/acp.c
Outdated
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.
no init
cujomalainey
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.
Please add codeowners and evaluate if you can also add any kernel build tests to CI as well. Did an initial review of common files, will review AMD specific code tomorrow
If we want to add any CI tests for GitHub compilation, we'd need to add AMD-specific fragments with a PR on https://github.com/thesofproject/kconfig |
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.
Nice to see the driver being used on further platforms! Sorry, I've only looked through the first two patches so far and also not very thoroughly, will try to continue later...
sound/soc/sof/amd/acp-dsp-offset.h
Outdated
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.
also a formatting / style thing: please use C-style /* */ comments
sound/soc/sof/amd/acp.c
Outdated
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.
instead of !(a == b) a != b is preferred
sound/soc/sof/amd/acp.c
Outdated
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.
...of use a for loop
sound/soc/sof/amd/acp.c
Outdated
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.
you might want some kind of wait_for_register() macro / inline function for all of these similar to snd_sof_dsp_read_poll_timeout() or maybe just re-use it
sound/soc/sof/amd/acp.c
Outdated
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.
val is unused. Does the register have to be read to acknowledge the IRQ or will this be used later? Otherwise looks like a needless operation?
sound/soc/sof/amd/acp.c
Outdated
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.
dsp_buf[index] = val looks prettier IMHO :-)
sound/soc/sof/amd/acp.c
Outdated
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.
no need for a type-cast from void
sound/soc/sof/amd/acp.c
Outdated
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.
superfluous initialisation
sound/soc/sof/amd/acp.c
Outdated
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.
src_buf[index]
|
cppcheck reports tons of warnings on this PR, worth looking into them @ajitkupandey |
|
Sparse reports some warnings as well |
|
and make W=1 is not happy either |
This is needed to compile thesofproject/linux#3054 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This is needed to compile thesofproject/linux#3054 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This is needed to compile thesofproject/linux#3054 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
@ajitkupandey last one for the day, the dependencies in the Kconfigs are not well modeled. If I use thesofproject/kconfig#59 and kconfig-sof-default.sh to generate the .config, the build fails ERROR: modpost: "snd_amd_acp_find_config" [sound/soc/sof/amd/snd-sof-amd-pci-rn.ko] undefined! which comes from the missing option: CONFIG_SND_SOC_AMD_ACP_COMMON is not set. |
ranj063
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.
LGTM
Ok, Thanks for the review comments. We will check the feasibility in the follow up PR very soon. |
This patch initializes ACP HW block to support SOF on AMD Renoir platform. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
ACP DMA is used for loading SOF firmware into DSP memory and data transfer from system memory to DSP memory. Add helper callbacks to initialize and configure ACP DMA block for fw loading. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
17a6667 to
dfaae5b
Compare
Add acp-loader module with ops callback to load and run firmware on ACP DSP block on Renoir platform. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add IPC module for generic ACP block and exposed ops callback for to synchronize SOF IPC message between host and DSP Signed-off-by: Balakishore Pati <Balakishore.pati@amd.com> Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add dsp ops callback to register I2S and DMIC sof dai's with ALSA Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add module to support ALSA pcm stream configurations for ACP I2S and DMIC endpoints Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
ACP hw block configuration differs across various distributions and hence it's required to register different drivers module for distributions. For now we support three ACP drivers: * ACP without SOF use case * ACP with SOF use case * ACP with SOF use case for DMIC and non SOF for I2S endpoints As all above driver registers with common PCI ID for ACP hw block we need code to determine ACP configuration and auto select driver module. This patch expose function that return configuration flag based on dmi checks for a system. ACP driver module probe register platform device based on such configuration flag to avoid conflict with other ACP drivers probed for same PCI ID. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add dsp ops callback to select and register machine driver. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add PCI driver module to enable sof pci device support for Renoir. If machine flag set to FLAG_SOF_ONLY_DMIC this pci driver register platform device for non dsp based I2S platform device. If machine flag is not enabled for SOF pci probe will return without invoking sof device probe and registration Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add new sof dais and config to pass topology file configuration to SOF firmware running on ACP's DSP core. ACP firmware support I2S_BT, I2S_SP and DMIC controller hence add three new dais to the list of supported sof_dais Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Add trace support and configure trace stream for ACP firmware. Signed-off-by: Vishnuvardhanrao Ravuapati <vishnuvardhanrao.ravulapati@amd.com> Signed-off-by: V sujith kumar Reddy <vsreddy@amd.com>
This patch add codeowners for AMD platform related SOF drivers. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
dfaae5b to
338e1ce
Compare
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.
@ajitkupandey, thank you for the fixes.
Looks OK from my side!
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.
nice job @ajitkupandey and AMD team.
|
Thank you all for the hard work on this! |
bardliao
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.
A nitpick, but still looks good to me.
|
|
||
| snd_sof_dsp_write(sdev, ACP_DSP_BAR, ACP_DSP0_RUNSTALL, ACP_DSP_RUN); | ||
| val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_DSP0_RUNSTALL); | ||
| dev_dbg(sdev->dev, "ACP_DSP0_RUNSTALL : 0x%0x\n", val); |
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.
nitpick: Do we need to return an error is val's value is not expected?
lyakh
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.
Comments can be addressed in an update or in a follow up PR, I'm fine either way
| unsigned int dscr_count, struct dma_descriptor *dscr_info) | ||
| { | ||
| struct snd_sof_dev *sdev = adata->dev; | ||
| int ret = 0; |
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.
superfluous initialisation
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.
Thanks for reviewing this .. will plan this for fix up series.
|
|
||
| #include <linux/firmware.h> | ||
| #include <linux/module.h> | ||
| #include <linux/pci.h> |
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.
I notice you removed multiple header includes from this and other files in this PR. Removing superfluous headers is good, but the required headers should be included. Quoting Documentation/process/submit-checklist.rst:
- If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
e.g. in this case you should explicitly include sof-priv.h, kernel.h, string.h, errno.h, device.h etc.
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.
Ok , we will do this in follow up PR with some fix up patch for headers.
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.
Is it really required to include all headers as mentioned in document ? because we don't see this been really followed in SOF core base and ASoC base. If we strictly need to follow that "quoted statement" we might need a fixup! patch for complete patch chain. For Eg: dev_dbg()/dev_err() facility is been used in all driver modules then kernel.h needs to be included in all c files where dev_dbg()/dev_err() has been used, but we don't see the same.
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.
strictly speaking that would be dev_printk.h, but AFAICS including device.h is also considered to be acceptable for this. The final word on this is certainly not mine, and yes, we're aware that this rule isn't perfectly strictly followed in SOF sources and even elsewhere around the kernel. Also, there are many cases where you actually should include a different file, not the one where the actual definition is made. dev_printk.h is one such example, but there are even stronger examples for that. E.g. if you need ffs() you don't #include <asm/bitops/ffs.h> you #include <linux/bitops.h> instead. But still you do include bitops.h instead of relying on it being included by kernel.h.
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.
@plbossart : Is it a mandatory at this moment? Do we really need a fix up for headers inclusion?
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.
@bhiregoudar it's strongly recommended. It's a difficult rule to apply and enforce, but the guidance is clear: try to avoid including headers in other headers, and only include them when they are used.
In many cases going through the list of headers actually has the effect to removing things that are not necessary and are included for no good reason.
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.
Sorry for delay in response. We won't be able to take these suggested changes as a fix up patch, but will create a separate new PR to accommodate these changes later
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.
please create a new PR with commits starting by 'fixup! ' so they can be auto-squashed.
kv2019i
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.
Thanks @ajitkupandey et al. Looks good to go. One question inline, but that is minor and don't see as an issue for merging.
| unsigned int offset = offsetof(struct scratch_ipc_conf, sof_out_box); | ||
|
|
||
| if (!substream || !sdev->stream_box.size) | ||
| acp_mailbox_read(sdev, offset, p, sz); |
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.
Is this intentional that you don't read any data when substream is non-NULL? This is for ipc_period_elapsed() and ipc_xrun().
|
Alright, there are no objections to merging the code in the SOF tree, so let's go ahead. @ajitkupandey please go ahead with fixup! patches, they will be squashed automagically with the original ones in the topic/sof-dev-rebase branch. |
|
Thank you all for the review and support. |
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.
@ajitkupandey, while trying to convert the AMD dtrace code to SOF client version, I stumbled on some of the implementation details, can you clarify them?
| return ret; | ||
| } | ||
|
|
||
| params->buffer.phy_addr = stream->reg_offset; |
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.
You are not using the dtrace page table allocated by the dtrace code (sdev->dmatp)? How the table gets to PTE_GRP8_OFFSET ?
| adata = sdev->pdata->hw_pdata; | ||
| stream = adata->dtrace_stream; | ||
| stream->dmab = &sdev->dmatb; | ||
| stream->num_pages = NUM_PAGES; |
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.
What happens if the dtrace is changed internally to use 18 pages for example?
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.
We are using 16 pages only but agreed we should not hardcode pages here .. I see this change is already taken care in #3136 .. we will test it and let you know
| return ret; | ||
| } | ||
|
|
||
| *stream_tag = stream->stream_tag; |
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.
*stream_tag is params->stream_tag
I think this has been overlooked during review.
What happens if the dtrace code internally changes and the stream_tag pointer is pointing to a lone u32 and not to the member of the struct sof_ipc_dma_trace_params_ext ?
You need to params to override some of the configured parameters, right?
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.
ok will fix this to params->stream_tag ..
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.
It is not an issue atm, just caused a bit of head scratching on my side when converting it to SOF client mode.
What could have been an issue is the assumption that the stream_tag is a member of the params struct. Which is, but an internal code change in dtrace and you would be in a big trouble...
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.
Agreed .. we can't assume that but ASFAIK currently we don't need a stream_tag to be filled in params as our fw is hardcoding stream tag. We will test trace support with sof client mode and let you know if stream_tag needed or not ?
|
|
||
| /* Trace Logger */ | ||
| .trace_init = acp_sof_trace_init, | ||
| .trace_release = acp_sof_trace_release, |
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.
You don't have .trigger? How do you start and stop the host DMA for trace?
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.
Actually we have DMA registers control in firmware code hence we don't need a trigger callback here.
This patch chain enable SOF kernel support for AMD Renoir platform.