-
Notifications
You must be signed in to change notification settings - Fork 349
[RFC]: Add support for drain operation #6112
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
[RFC]: Add support for drain operation #6112
Conversation
Added a new IPC stream structure that will be used by the FW in order to notify the host that the drain operation is done. For the moment, the structure contains only the reply header since that's the only information we care about but, by adding a new IPC stream structure, we can send more information from FW regarding the drain operation if need be. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Added a new function used to notify the host that the drain operation has finished. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Added a few macros to prepare for drain operation support. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
|
We need to also fix this: https://github.com/thesofproject/sof/runs/7746781189?check_suite_focus=true the mockup functions. |
b2e0711 to
483f7e4
Compare
Since we want to support the drain operation we need to add a new case to the ipc_stream_trigger function that will handle the TRIG_DRAIN IPC message received from the host when the drain operation is to be started. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
483f7e4 to
3791795
Compare
We want to handle the TRIG_DRAIN IPC message from host. We're not really interested in changing the state of the components to COMP_STATE_DRAINING because, during draining, they behave as if they were in COMP_STATE_ACTIVE. Also, we're not really going to use the state of the components to figure out when to notify the host that the draining is over. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
In order to handle the DRAIN operation, we first need to set the state of each of the pipelines to COMP_STATE_DRAINING. Having entered the COMP_STATE_DRAINING, if the pipeline_copy operation return value is <= 0 we can conclude that the draining is done and we can send a notification to the host (also we should set the state of the pipeline back to COMP_STATE_ACTIVE) Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
|
thanks @LaurentiuM1234 I will add this topic on the list for tomorrow meeting with @plbossart and Intel folks. |
| * if it's <= 0 then the draining opearation is over | ||
| * and we need to send a notification to the host | ||
| */ | ||
| if (err <= 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.
what cases of err > 0 are possible here and what should be done then? Do any .copy methods return PPL_STATUS_PATH_STOP? I haven't found any such cases
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.
For some reason I was under the wrong impression that pipeline_copy would return >0 in case of success and <=0 otherwise (=0 meaning it couldn't copy data) but that's not really the case.
|
Closing this along with thesofproject/linux#3808 since this solution is really bad. Will reopen when I'll have something more solid. |
Associated kernel PR: thesofproject/linux#3808
This, like the kernel PR, is a rough attempt of implementing support for the drain operation.
Notes:
comp_set_state(): wrong state = 5, COMP_TRIGGER_RESET. I was wondering why the transition from ACTIVE to READY is somewhat treated like an error? (somewhat because it prints an error message but it still changes the state)