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

Upstream: Patch 5/14: pcm: need comments on non-atomic trigger #421

Closed
plbossart opened this issue Dec 12, 2018 · 8 comments · Fixed by #506
Closed

Upstream: Patch 5/14: pcm: need comments on non-atomic trigger #421

plbossart opened this issue Dec 12, 2018 · 8 comments · Fixed by #506
Assignees
Labels
enhancement New feature or request upstream blocker Mandatory for upstream

Comments

@plbossart
Copy link
Member

need to explain why the trigger is not atomic (and that it's based on FEs with .nonatomic=true)

@ranj063
Copy link
Collaborator

ranj063 commented Dec 13, 2018

@plbossart I think that the whole pcm trigger in SOF is non-atomic and the reason is that we use the ipc to trigger the operation which is a schedulable call and is not atomic.

But we do not explicitly set nonatomic to true for the FE's. Should we do that?

Furthermore, I just checked the machine driver and Isee that all the FE dai defs there set nonatomic to 1.

@plbossart
Copy link
Member Author

plbossart commented Dec 13, 2018 via email

@libinyang
Copy link

libinyang commented Dec 14, 2018

I think Pierre is right. We do set the nonatomic in the FE. This will make sure that alsa core will call our functions in nonatomic environment.
In soc-pcm, it will set snd_pcm->nonatomic = rtd->dai_link->nonatomic.
In alsa core pcm_native.c, it will check snd_pcm->nonatomic to determine whether use spin_lock or not.
And alsa uses our FE snd_pcm as the interface. So I believe it is safe for our cases. And just adding some comments like Takashi suggested should be enough.

@plbossart
Copy link
Member Author

@libinyang thanks for looking into this. So we are covered for FEs, but as Ranjani mentions it I don't get what happens for BEs. It's supposed to be atomic at that level, at least if you look at the previous solutions with closed source firmware all BEs where configured with .nonatomic=false (implicitly).

@libinyang
Copy link

For BE, let me use hw_params as an example, I believe other are the same.

For dynamic link, dpcm_fe_dai_hw_params() is the interface. ALSA core will call this function, and then the dpcm_fe_dai_hw_params() will call dpcm_be_dai_hw_params(). This means BE hw_params is called by the FE hw_params. If we can make sure FE is nonatomic, then BE should be nonatomic too.

@plbossart
Copy link
Member Author

@libinyang if you look at the machine drivers for all previous solutions based on closed-source firmware, the BEs are always marked as .nonatomic=false. So why would SOF require non-atomic operation when others using the same hardware did not? Either they are all wrong or we are.

@libinyang
Copy link

@plbossart
I grepped our source code, and didn't find the setting .nonatomic=false. Maybe the old code is not merged into our branch?
However, closed-source firmware may use a different solution. From our current code, we may sleep in our sof code, so we use .nonatomic=true. Maybe closed source doesn't sleep when ALSA core calls them?
And besides, for our SOF code, we use FE to expose PCM to the userspace. This means user will operate on FE directly in alsa core level. And ASoC will call BE functions when operating on FE callbacks. I'm not sure how closed source's behavior. Maybe @lgirdwood know the story.

@plbossart
Copy link
Member Author

plbossart commented Dec 17, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request upstream blocker Mandatory for upstream
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants