-
Notifications
You must be signed in to change notification settings - Fork 322
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
Preparatory patches for NXP platforms transition to Zephyr native drivers #8859
Preparatory patches for NXP platforms transition to Zephyr native drivers #8859
Conversation
8686295
to
10c85b6
Compare
zephyr/lib/dma.c
Outdated
.plat_data = { | ||
.dir = DMA_DIR_MEM_TO_DEV | DMA_DIR_DEV_TO_MEM, | ||
.devs = DMA_DEV_SAI, | ||
.channels = 64, /* TODO: this shouldn't be hardcoded */ |
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 device tree property?
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 such property ATM (dma-channels
can't be used for EDMA)
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 can be added later in DT and updated here when Zephyr side is ready.
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.
.channels = 64, /* TODO: this shouldn't be hardcoded */ | |
.channels = 64, /* TODO: add a new DT property in Zephyr */ |
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.
About this: we do already have a DT property for this (there's 2 channel count-related ones actually). The issue is that they don't necessarily tell you what the max number of channels* is (which I'm assuming should be the value we want here). Anyways, for now I'd prefer sticking with the generic comment until we fix this via making use of (one) the already existing two properties.
(*) or the number of contiguous channels
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's not because you're not sure yet how to fix this TODO that you should be holding back the information that you already have. Comments are cheap and you already wrote them just now. Why not have this knowledge directly in the source code? Readers rarely go all the way back to the code review. You may or may not be the one who will fix this later and even if it's you, you will most likely have forgotten half of it in a few months as we typically all do.
Don't get me wrong: I hate pointlessly verbose comments that just paraphrase the code - which should ideally be so clear and easy to read that it does not require any comment. But this situation here looks like the exact opposite.
My 2 cents.
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.
Fair point, tweaked the comment to make it a bit more useful while still keeping it short
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. Just some questions on one-shot
src/audio/host-zephyr.c
Outdated
@@ -213,6 +214,15 @@ static int host_copy_one_shot(struct host_data *hd, struct comp_dev *dev, copy_c | |||
return ret; | |||
} | |||
|
|||
if (IS_ENABLED(CONFIG_DMA_NXP_SOF_HOST_DMA)) { |
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 would say this is probably a common feature - i.e. we allocate a DMA channels and then should be able to use it for several one shot copies (with different SRC/DST addresses).
@kv2019i @lyakh @abonislawski can you see any problems if we always reload src/dst/size for every one shot copy ?
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.
Now this is performed for all platforms. Let's see if this breaks any tests. If not, we can probably keep it this way for now.
src/audio/dai-zephyr.c
Outdated
@@ -718,6 +718,15 @@ static int dai_set_dma_config(struct dai_data *dd, struct comp_dev *dev) | |||
dma_block_cfg->block_size = config->elem_array.elems[i].size; | |||
dma_block_cfg->source_address = config->elem_array.elems[i].src; | |||
dma_block_cfg->dest_address = config->elem_array.elems[i].dest; | |||
if (IS_ENABLED(CONFIG_DMA_NXP_EDMA)) { |
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.
should this be a common thing we should always do ?
@abonislawski @kv2019i @lyakh pls 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.
Looks like it should be safe to make this generic - Intel drivers don't use .source_addr_adj
and .dest_addr_adj
10c85b6
to
bcedade
Compare
V2 changes
|
bcedade
to
4ff4ccb
Compare
zephyr/lib/dma.c
Outdated
.plat_data = { | ||
.dir = DMA_DIR_MEM_TO_DEV | DMA_DIR_DEV_TO_MEM, | ||
.devs = DMA_DEV_SAI, | ||
.channels = 64, /* TODO: this shouldn't be hardcoded */ |
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 can be added later in DT and updated here when Zephyr side is ready.
Since the DMAC is configured in a somewhat different way in the native case vs the non-native case, add a native version of the ipc_get_page_descriptors() function and remove the Zephyr-specific functions from the non-native version of said function. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
With every copy() operation, the source and destination addresses keep getting modified. As such, for each re-configuration performed during host_copy_one_shot(), the HOST DMAC needs to be made aware of these changes. This commit changes host_copy_one_shot() such that on each dma_config() call the DMAC driver receives the updated addresses and size. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Source and destination addresses cannot be NULL. As such, set them to the values found in the first element of hd->config's elem_array. This is fine to do because the host component uses only 1 block. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
4ff4ccb
to
3c9f723
Compare
V3 changes
|
Lot of red on the CI results - lets run again to make sure it's not a DUT issue. |
SOFCI TEST |
3c9f723
to
855ac8e
Compare
Since the Zephyr SAI driver is now enabled, add an entry in the zephyr_dev array, which will resolve to multiple "struct device *", one for each SAI node specified in the DTS. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Noticing some failures in the internal Intel CI. @marc-hb @lgirdwood would it be possible to dump the output of the job here (or at least the part that fails). Hopefully that'll give us a clue as to which part of this PR breaks it. |
@wszypelt @lrudyX can you provide the logs or its it a false positive result ? |
I had a quick look at the internal version of https://sof-ci.01.org/sof-pr-viewer/#/build/PR8859/build13666634 and it does not look like false positives because less than 10% of the tests failed and I didn't see any of the usual signs of false positives, I mean no "network timeout" and no "directory not found" error message. Most failing tests seem to have "loopback" in the name in case that helps.
We used to have that, then a forced change of web provider broke the (too complex) site javascript and no one still working on the project knows how to fix it (internal issue 307). Apologies. HOWEVER there are many sof-test failures in MTL https://sof-ci.01.org/sofpr/PR8859/build3069/devicetest/index.html and in CAVS https://sof-ci.01.org/sofpr/PR8859/build3070/devicetest/index.html and you should have complete logs there. Please start there instead. Unlike the other tests, sof-test is open-source so you might even be able to reproduce? Obviously, smaller PRs also help: |
855ac8e
to
2bdb428
Compare
V4 changes
|
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.
@LaurentiuM1234 your code looks clean and platform specific and I would not expect a breaker for other platforms, but I could be wrong as the CI results are not yet showing, but pls do check again in an hour or two.
Another unfortunate side-effect: it is NOT possible to find earlier test results after a force push. When discussing test results, always "save" the URL in the comments.
For years our suspend/resume pass rate has been between 80% and 100%. If you see observe anything in that range then it's fairly safe to assume no regression from this PR. There is also one frequent pause/resume failure on MTL, I think there's already a bug filed for it. |
Since the EDMA and HOST DMA nodes have been introduced to the i.MX93 overlay, add entries in the dma array which will create a struct dma for each of these DMACs. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Since now there's a Zephyr driver for NXP's SAI, the dai_set_config() should be modified to also allow the configuration of the SAI. As such, this commit introduces a new case for NXP's SAI that does exactly that. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Some DMACs (e.g: NXP's EDMA) can automatically adjust the source and destination addresses upon transfer completion. As such, we need to indicate how the adjustment should be performed. In the case of playback, the source address should be decremented, while in the case of capture, the destination address should be decremented. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Currently, the DAI component's state is not updated on dai_trigger() operation, which leads to pipeline_comp_copy() skipping the dai_copy() operation (since the DAI component never transitions to the ACTIVE state). To fix this, add a state transition in dai_comp_trigger_internal(). Also, make sure not to trigger the DAI component if already in the requested state. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
In the case of some DAIs, the DMA slot may be encoded differently in the DAI configuration handshake. As such, we can't count on the fact that the handshake itself can be used as the DMA slot. To fix this, add a function which parses the handshake and allows each DAI to use its own encoding of the DMA slot inside the handshake. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The native SAI and ESAI drivers use a different handshake encoding. As such, when using native Zephyr drivers use a different function for decoding the channel from the handshake. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
2bdb428
to
a0a034a
Compare
@iuliana-prodan @dbaluta good with the latest update ? |
@lgirdwood all good on our side. |
This PR is a combination of patches cherry-picked from #8520 and #8844. These patches don't require a Zephyr hash bump and are needed for the transition of NXP platforms to native Zephyr drivers.