* core: snd_card_disconnect/snd_card_free: hang when card unregistered @ 2020-05-14 21:04 Dexter Travis 2020-05-15 7:32 ` Takashi Iwai 0 siblings, 1 reply; 4+ messages in thread From: Dexter Travis @ 2020-05-14 21:04 UTC (permalink / raw) To: alsa-devel In my system during certain power events the power rail for the TLV320AIC3120 goes away and may come back. To accommodate this I have added a call to snd_soc_unregister_card as soon as I notice via GPIO that this power has been removed. I then call snd_soc_register_card to re-install the sound card after power is restored. If no sound is playing when the asynchronous power removal occurs this works fine. If a sound is playing one of two things will occur. In the first case the sound driver comes back and sound is restored when power is restored. In the second case my deferred work function which calls the snd_soc_unregister_card function gets hung and does not return. I have traced the difference to the wait_for_completion call in snd_card_free. if snd_card_disconnect adds files to shutdown_files list then wait_for_completion will hang forever. Any suggestions on how to further debug this? How to force the immediate unregister of the card even if a sound is playing? Thank you, Dexter Travis ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: core: snd_card_disconnect/snd_card_free: hang when card unregistered 2020-05-14 21:04 core: snd_card_disconnect/snd_card_free: hang when card unregistered Dexter Travis @ 2020-05-15 7:32 ` Takashi Iwai 2020-05-15 13:30 ` Dexter Travis 0 siblings, 1 reply; 4+ messages in thread From: Takashi Iwai @ 2020-05-15 7:32 UTC (permalink / raw) To: Dexter Travis; +Cc: alsa-devel On Thu, 14 May 2020 23:04:09 +0200, Dexter Travis wrote: > > In my system during certain power events the power rail for the > TLV320AIC3120 goes away and may come back. > > To accommodate this I have added a call to snd_soc_unregister_card as > soon as I notice via GPIO that this power has been removed. I then > call snd_soc_register_card to re-install the sound card after power is > restored. > > If no sound is playing when the asynchronous power removal occurs this > works fine. > > If a sound is playing one of two things will occur. In the first case > the sound driver comes back and sound is restored when power is > restored. In the second case my deferred work function which calls the > snd_soc_unregister_card function gets hung and does not return. > > I have traced the difference to the wait_for_completion call in > snd_card_free. if snd_card_disconnect adds files to shutdown_files > list then wait_for_completion will hang forever. > > Any suggestions on how to further debug this? > > How to force the immediate unregister of the card even if a sound is playing? You can unregister the devices, i.e. they disappear from the user-space. However, the old stream and the belonging objects are still alive, hence you can't release the resources entirely until the user-space closes and drops the remaining one. The completion is waiting for the release of those remaining handles. So, if you try to register again the same objects, it'll conflict. IOW, it'll be really messy if you try to disconnect and release the whole resources temporarily and restore again. I guess the current best would be to limit a part of components somehow during the temporary absence. The temporary stop of a stream isn't well handled in the core API, admittedly, it's a known problem. We're considering to introduce a new state, but it's still under evaluation. thanks, Takashi ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: core: snd_card_disconnect/snd_card_free: hang when card unregistered 2020-05-15 7:32 ` Takashi Iwai @ 2020-05-15 13:30 ` Dexter Travis 2020-05-15 14:35 ` Takashi Iwai 0 siblings, 1 reply; 4+ messages in thread From: Dexter Travis @ 2020-05-15 13:30 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel Takashi, Thank you. That is helpful. In my case we are embedded deeply enough that there is only one application playing sounds so it may be possible to improve our user space side to properly close down the sound. When power comes back I do not need to resume playing the previous sound. From the kernel side is it possible to force the sound to abort or stop? How do more easily removed sound devices handle this? For example a USB or other hot-pluggable sound device? Regards, Dexter On Fri, May 15, 2020 at 2:32 AM Takashi Iwai <tiwai@suse.de> wrote: > > On Thu, 14 May 2020 23:04:09 +0200, > Dexter Travis wrote: > > > > In my system during certain power events the power rail for the > > TLV320AIC3120 goes away and may come back. > > > > To accommodate this I have added a call to snd_soc_unregister_card as > > soon as I notice via GPIO that this power has been removed. I then > > call snd_soc_register_card to re-install the sound card after power is > > restored. > > > > If no sound is playing when the asynchronous power removal occurs this > > works fine. > > > > If a sound is playing one of two things will occur. In the first case > > the sound driver comes back and sound is restored when power is > > restored. In the second case my deferred work function which calls the > > snd_soc_unregister_card function gets hung and does not return. > > > > I have traced the difference to the wait_for_completion call in > > snd_card_free. if snd_card_disconnect adds files to shutdown_files > > list then wait_for_completion will hang forever. > > > > Any suggestions on how to further debug this? > > > > How to force the immediate unregister of the card even if a sound is playing? > > You can unregister the devices, i.e. they disappear from the > user-space. However, the old stream and the belonging objects are > still alive, hence you can't release the resources entirely until the > user-space closes and drops the remaining one. The completion is > waiting for the release of those remaining handles. So, if you try to > register again the same objects, it'll conflict. > > IOW, it'll be really messy if you try to disconnect and release the > whole resources temporarily and restore again. I guess the current > best would be to limit a part of components somehow during the > temporary absence. > > The temporary stop of a stream isn't well handled in the core API, > admittedly, it's a known problem. We're considering to introduce a > new state, but it's still under evaluation. > > > thanks, > > Takashi ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: core: snd_card_disconnect/snd_card_free: hang when card unregistered 2020-05-15 13:30 ` Dexter Travis @ 2020-05-15 14:35 ` Takashi Iwai 0 siblings, 0 replies; 4+ messages in thread From: Takashi Iwai @ 2020-05-15 14:35 UTC (permalink / raw) To: Dexter Travis; +Cc: alsa-devel On Fri, 15 May 2020 15:30:25 +0200, Dexter Travis wrote: > > Takashi, > > Thank you. That is helpful. In my case we are embedded deeply enough > that there is only one application playing sounds so it may be > possible to improve our user space side to properly close down the > sound. > > When power comes back I do not need to resume playing the previous > sound. From the kernel side is it possible to force the sound to > abort or stop? That can be done by calling snd_pcm_stop(). The function needs the stream locking. You can use snd_pcm_stop_xrun() instead, although it's no XRUN, strictly speaking. > How do more easily removed sound devices handle this? For example a > USB or other hot-pluggable sound device? In the case of actually removed device, the whole device is gone, and at re-plugging, a new device gets created, hence no conflicts between them. They are two different devices, after all. Takashi > > > > Regards, > > > Dexter > > On Fri, May 15, 2020 at 2:32 AM Takashi Iwai <tiwai@suse.de> wrote: > > > > On Thu, 14 May 2020 23:04:09 +0200, > > Dexter Travis wrote: > > > > > > In my system during certain power events the power rail for the > > > TLV320AIC3120 goes away and may come back. > > > > > > To accommodate this I have added a call to snd_soc_unregister_card as > > > soon as I notice via GPIO that this power has been removed. I then > > > call snd_soc_register_card to re-install the sound card after power is > > > restored. > > > > > > If no sound is playing when the asynchronous power removal occurs this > > > works fine. > > > > > > If a sound is playing one of two things will occur. In the first case > > > the sound driver comes back and sound is restored when power is > > > restored. In the second case my deferred work function which calls the > > > snd_soc_unregister_card function gets hung and does not return. > > > > > > I have traced the difference to the wait_for_completion call in > > > snd_card_free. if snd_card_disconnect adds files to shutdown_files > > > list then wait_for_completion will hang forever. > > > > > > Any suggestions on how to further debug this? > > > > > > How to force the immediate unregister of the card even if a sound is playing? > > > > You can unregister the devices, i.e. they disappear from the > > user-space. However, the old stream and the belonging objects are > > still alive, hence you can't release the resources entirely until the > > user-space closes and drops the remaining one. The completion is > > waiting for the release of those remaining handles. So, if you try to > > register again the same objects, it'll conflict. > > > > IOW, it'll be really messy if you try to disconnect and release the > > whole resources temporarily and restore again. I guess the current > > best would be to limit a part of components somehow during the > > temporary absence. > > > > The temporary stop of a stream isn't well handled in the core API, > > admittedly, it's a known problem. We're considering to introduce a > > new state, but it's still under evaluation. > > > > > > thanks, > > > > Takashi > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-15 14:36 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-14 21:04 core: snd_card_disconnect/snd_card_free: hang when card unregistered Dexter Travis 2020-05-15 7:32 ` Takashi Iwai 2020-05-15 13:30 ` Dexter Travis 2020-05-15 14:35 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.