Skip to content
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

Audio: Fix the errors of dai timestamp ops #8192

Merged
merged 3 commits into from
Sep 18, 2023

Conversation

andrula-song
Copy link
Contributor

use the ts_config of struct dai_data as input/output parameter instead a temporary variable while calling the dai timestamp functions.

@@ -1669,7 +1669,7 @@ static int dai_copy(struct comp_dev *dev)
int dai_common_ts_config_op(struct dai_data *dd, struct comp_dev *dev)
{
struct ipc_config_dai *dai = &dd->ipc_config;
struct dai_ts_cfg cfg;
struct dai_ts_cfg *cfg = (struct dai_ts_cfg *)&dd->ts_config;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we actually have struct dai_ts_cfg identical to struct timestamp_cfg and struct dai_ts_data identical to struct timestamp_data?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The content of both struct is the same, and the final function in zephyr/driver/dai/intel/ needs such input parameter.

Copy link
Collaborator

@lyakh lyakh Sep 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, so would it be possible to drop struct timestamp_cfg and struct timestamp_data completely and use struct dai_ts_cfg and struct dai_ts_data instead everywhere?
EDIT: if we need those copies for XTOS, then we could call them the same as for Zephyr and put under #ifdef

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, then I would like to redefine the struct struct dai_data.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I think that would be good - and define copies of those structures in dai-legacy.h under #ifndef __ZEPHYR__

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if we are using dai_legacy.c, we will use the original struct timestamp_cfg and struct timestamp_data(because the original interface without zephyr needs such input parameters). So I don't think it is good to redefine struct dai_data in dai-legacy.h in this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, we can rename them for legacy, right? And no, it doesn't have to be fixed in this PR

Copy link
Contributor Author

@andrula-song andrula-song Sep 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then I'd like to use another PR to redefine for legacy, because I can not test it before I push code to PR right now.

Copy link
Contributor

@btian1 btian1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we say this is a bug fix?

use the ts_config of struct dai_data as input/output
parameter instead a temporary variable while calling
the dai timestamp functions.

Signed-off-by: Andrula Song <[email protected]>
Use struct dai_ts_data replace timestamp_data if
CONFIG_ZEPHYR_NATIVE_DRIVERS is enabled.

Signed-off-by: Andrula Song <[email protected]>
Use struct dai_ts_cfg replace timestamp_cfg of struct
dai_data in dai-zephyr.h

Signed-off-by: Andrula Song <[email protected]>
@kv2019i kv2019i merged commit 2ede148 into thesofproject:main Sep 18, 2023
41 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants