Skip to content

Conversation

@LaurentiuM1234
Copy link
Contributor

Associated kernel PR: thesofproject/linux#3808

This, like the kernel PR, is a rough attempt of implementing support for the drain operation.

Notes:

  • because of the fact that the FW expects to receive a TRIG_STOP before receiving a PCM_FREE an error message will be printed before changing the state from ACTIVE to READY: 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)

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>
@dbaluta
Copy link
Collaborator

dbaluta commented Aug 9, 2022

We need to also fix this:

https://github.com/thesofproject/sof/runs/7746781189?check_suite_focus=true

the mockup functions.

@LaurentiuM1234 LaurentiuM1234 marked this pull request as draft August 9, 2022 13:35
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>
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>
@dbaluta
Copy link
Collaborator

dbaluta commented Aug 9, 2022

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) {
Copy link
Collaborator

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

Copy link
Contributor Author

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.

@LaurentiuM1234
Copy link
Contributor Author

Closing this along with thesofproject/linux#3808 since this solution is really bad. Will reopen when I'll have something more solid.

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.

3 participants