All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Dexter Travis <dexter.travis@precisionplanting.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: core: snd_card_disconnect/snd_card_free: hang when card unregistered
Date: Fri, 15 May 2020 09:32:27 +0200	[thread overview]
Message-ID: <s5hsgg1odpw.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAOyfbRXsKi-7bvnRNhoR6Vu7ET1oM5CJ6tEKwcDchy48ExpFvQ@mail.gmail.com>

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

  reply	other threads:[~2020-05-15  7:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2020-05-15 13:30   ` Dexter Travis
2020-05-15 14:35     ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hsgg1odpw.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=dexter.travis@precisionplanting.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.