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

DMIC: eliminate the gain ramping task #5852

Merged
merged 3 commits into from
Jun 10, 2022
Merged

Conversation

lyakh
Copy link
Collaborator

@lyakh lyakh commented May 24, 2022

The DMIC driver currently uses a separate task to perform gain ramping on start up. This can be achieved from the .copy() context avoiding an additional asynchronous context and races associated with it.

@marcinszkudlinski
Copy link
Contributor

marcinszkudlinski commented May 24, 2022

@juimonen, pls take a look, we need to sync changes with zephyr dai.

@wszypelt
Copy link

wszypelt commented May 24, 2022

Internal tests are not working properly now.
Please be patient, there are problems with the internal service, we will try to fix it within 24 hours

Copy link
Member

@lgirdwood lgirdwood 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 simplify and do the ramp at the start of copy() instead of adding another callback ?

@marcinszkudlinski
Copy link
Contributor

Can we simplify and do the ramp at the start of copy() instead of adding another callback ?
@lgirdwood, Dmic driver code is not involved in copy operation, so there's nothing like "start of copy()" in dmic.c code.

@lgirdwood
Copy link
Member

Can we simplify and do the ramp at the start of copy() instead of adding another callback ?
@lgirdwood, Dmic driver code is not involved in copy operation, so there's nothing like "start of copy()" in dmic.c code.

I think it makes sense here to add copy() to the DAIs (like everything else) and keep the interface simple (and saves an extra call)

@marcinszkudlinski
Copy link
Contributor

Can we simplify and do the ramp at the start of copy() instead of adding another callback ?
@lgirdwood, Dmic driver code is not involved in copy operation, so there's nothing like "start of copy()" in dmic.c code.

I think it makes sense here to add copy() to the DAIs (like everything else) and keep the interface simple (and saves an extra call)

It is just a matter of name, .copy or .pre_copy - would be called anyway at the same moment. The point is - this method does not do any copying, it is a dma/dai job
.pre_copy maybe a more accurate name in fact

@lgirdwood
Copy link
Member

Can we simplify and do the ramp at the start of copy() instead of adding another callback ?
@lgirdwood, Dmic driver code is not involved in copy operation, so there's nothing like "start of copy()" in dmic.c code.

I think it makes sense here to add copy() to the DAIs (like everything else) and keep the interface simple (and saves an extra call)

It is just a matter of name, .copy or .pre_copy - would be called anyway at the same moment. The point is - this method does not do any copying, it is a dma/dai job .pre_copy maybe a more accurate name in fact

Agree, copy() naming does not align with usage today - but soon this call will be updated to the module C API and be called process() and this is a better naming/meaning match. Adding a new API adds a bit more complexity when it comes to the module API and I'd like to avoid and reuse (where good mapping permits).

@lyakh
Copy link
Collaborator Author

lyakh commented May 27, 2022

Can we simplify and do the ramp at the start of copy() instead of adding another callback ?
@lgirdwood, Dmic driver code is not involved in copy operation, so there's nothing like "start of copy()" in dmic.c code.

I think it makes sense here to add copy() to the DAIs (like everything else) and keep the interface simple (and saves an extra call)

It is just a matter of name, .copy or .pre_copy - would be called anyway at the same moment. The point is - this method does not do any copying, it is a dma/dai job .pre_copy maybe a more accurate name in fact

Agree, copy() naming does not align with usage today - but soon this call will be updated to the module C API and be called process() and this is a better naming/meaning match. Adding a new API adds a bit more complexity when it comes to the module API and I'd like to avoid and reuse (where good mapping permits).

@lgirdwood but I should call it .copy() now, not .process() directly?

@lgirdwood
Copy link
Member

@lgirdwood but I should call it .copy() now, not .process() directly?

Yes, call it copy() today - there will be a subsequent update that then renames later and aligns with the module API.

@lgirdwood
Copy link
Member

@lyakh @singalsu do we expect the gain ramp to change (and fail tests) ? we are seeing a failure on the DMIC tests on internal CI.

@singalsu
Copy link
Collaborator

@lyakh @singalsu do we expect the gain ramp to change (and fail tests) ? we are seeing a failure on the DMIC tests on internal CI.

The capture ramps have been the same for a long time. If something has changed there could be a new bug. But I don't think CI tests the ramp shape, it can only detect no audio or much too silent audio kind of cases.

@lyakh
Copy link
Collaborator Author

lyakh commented May 31, 2022

Two CI tests failed with a timeout: suspend-resume-with-playback on WHL_UPEXT_HDA_ZEPHYR https://sof-ci.01.org/sofpr/PR5852/build515/devicetest/?model=WHL_UPEXT_HDA_ZEPHYR&testcase=check-suspend-resume-with-playback-5 and ipc-flood on BYT_MB_NOCODEC https://sof-ci.01.org/sofpr/PR5852/build515/devicetest/?model=BYT_MB_NOCODEC&testcase=check-ipc-flood - both supposedly unrelated

Copy link
Collaborator

@singalsu singalsu left a comment

Choose a reason for hiding this comment

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

Looks good to me, great work! There's some conflict, so a rebase is needed.

@lgirdwood
Copy link
Member

Rerun CI as not expecting a build failure on only 1 platform.

@lgirdwood
Copy link
Member

SOFCI TEST

Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

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

@lyakh Documentation of the new copy() method could be improved in the first patch, but otherwise this looks great.

@@ -86,6 +86,7 @@ struct dai_ops {
int (*remove)(struct dai *dai);
uint32_t (*get_init_delay_ms)(struct dai *dai);
int (*get_fifo_depth)(struct dai *dai, int direction);
void (*copy)(struct dai *dai);
Copy link
Collaborator

Choose a reason for hiding this comment

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

A bit of documentation would be nice. In the context of the dmic problem this is easily understandable, but if you zoom out a bit, a copy method with no arguments looks very odd. Copy what and where?

@lgirdwood
Copy link
Member

@mmaka1 did you have any comments here - is this OK as part of the path forward to a copier API ?

lyakh added 3 commits June 8, 2022 17:27
Add a DAI copy method to be called before dma_copy().

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
DAI drivers sometimes need to access the underlying component object.
Make this possible by adding a pointer to struct dai_data into struct
dai and to struct comp_dev into struct dai_data and by assigning
those pointers accordingly.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Currently the DMIC driver uses a separate task to implement its gain
ramping. This creates a race during driver clean up. Avoid an
additional asynchronous context by performing the ramping in DAI's
.copy() context. Use the DAI's .copy() method for that.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
@lyakh
Copy link
Collaborator Author

lyakh commented Jun 9, 2022

@lgirdwood CI on-device are 2 unrelated suspend -resume failures: https://sof-ci.01.org/sofpr/PR5852/build602/devicetest/?model=TGLU_UP_HDA_ZEPHYR&testcase=check-suspend-resume-5 and https://sof-ci.01.org/sofpr/PR5852/build602/devicetest/?model=WHL_UPEXT_HDA_ZEPHYR&testcase=check-suspend-resume-with-capture-5, checkpatch is complaining about a line, ending in '(' which I agree isn't pretty but looked like the best option in that case to avoid way too long a line

@lgirdwood
Copy link
Member

@mmaka1 ping ?

@lgirdwood
Copy link
Member

Merging since this fixes an issue, we can align to copier APIs incrementally.

@lgirdwood lgirdwood merged commit e56e88d into thesofproject:main Jun 10, 2022
@lyakh lyakh deleted the dmic-ramp branch June 13, 2022 06:15
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