Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Stas Sergeev <stsp@aknet.ru>
Cc: alsa-devel@alsa-project.org
Subject: Re: snd_pcsp locking mess
Date: Thu, 21 Aug 2008 11:06:19 +0200	[thread overview]
Message-ID: <s5hej4ibuus.wl%tiwai@suse.de> (raw)
In-Reply-To: <48AD21EF.8010906@aknet.ru>

At Thu, 21 Aug 2008 12:06:07 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Takashi Iwai wrote:
> > Maybe codes tell better than words.  The below is my untested patch.
> I finally got around to have a
> look at the patch and gave it
> some testing.
> I think it is the best solution
> for what we currently have, but
> I see a few simplifications to
> it if some simple changes to the
> alsa core are done.
> 
> 1. We can have only one sync point
> instead of many, and that should
> be the stop callback. It is not
> possible right now because the stop
> callback can be asynchronous. This
> can be solved by providing the separate
> callback to be called from snd_pcm_period_elapsed().
> I already proposed this a few years
> ago and made a patch, but it was
> rejected in favour of the current
> excessive locking we have in pcsp.
> But now as we are at simplifying
> it, I wonder if that idea can be
> re-evaluated. Note that the change
> was not intrusive at all. The new
> callback was optional. If it is
> not provided, then the old logic
> applies.

I don't remember exactly, but adding a new callback doesn't sound so
perfect.  Well, it's just one pointer, but it's added all over
places.

Anyway, could you repost it?  Then we can discuss about it more
concretely.


> 2.
> >>> +/*
> >>> > > + * Force to stop and sync the stream
> >>> > > + */
> >>> > > +void pcsp_sync_stop(struct snd_pcsp *chip)
> >>> > > +{
> >>> > > +	local_irq_disable();
> >> > So what will happen if the timer callback
> >> > is executing on another CPU at that point?
> > That doesn't matter, because this irqsave is needed just for
> > i8253_lock in pcsp_stop_playing() (as it doesn't save irq).
> local_irq_disable() can be avoided
> as well by introducing the separate
> async stop callback.

It'll be nice, then.


> 3. The AB/BA locking can be avoided
> without the use of the softirq I think.
> Right now snd_pcm_period_elapsed()
> takes the pcm_stream_lock() because
> it calls the stop callback which needs
> that lock. But, having the separate
> stop callback, snd_pcm_period_elapsed()
> may probably just take some other lock
> for its internal needs, and take the
> pcm_stream_lock() only if the separate
> stop callback is not provided.
> 
> The above changes look fairly simple,
> and I even had the patch for 1 already.
> The changes to snd-pcsp will became
> much simpler with them I beleive.
> And having the possibility to provide
> a separate callback for the IRQ context
> looks like the really must-have thing
> to me from the very beginning. I even
> remember the old OSS callbacks which
> were passed the flag to indicate whether
> or not they are called from an IRQ
> context. I prefer the separate callback
> to the flag, but in alsa there is currently
> neither.

Well, the IRQ context and locking are different things.
A known problem with PCM substream lock is that it's to be used for
multiple bound streams as well.  My concern is whether this can be
still avoided well by your changes.

But, in general, I'd love to clean up the PCM stuff, especially these
lock messes.  Let's cook a stew a bit more.


thanks,

Takashi

  reply	other threads:[~2008-08-21  9:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080518172258.D0DFB108060@picon.linux-foundation.org>
2008-05-18 18:20 ` snd_pcsp locking mess Stas Sergeev
2008-05-19  5:50   ` Takashi Iwai
2008-05-19 17:01     ` Stas Sergeev
2008-05-21 12:33       ` Takashi Iwai
2008-05-22 20:28         ` Stas Sergeev
2008-05-23 10:51           ` Takashi Iwai
2008-05-27 13:46             ` Stas Sergeev
2008-05-27 13:47             ` Stas Sergeev
2008-05-27 15:50               ` Takashi Iwai
2008-05-27 17:40                 ` Stas Sergeev
2008-05-28 10:13                   ` Takashi Iwai
2008-05-28 20:08                     ` Stas Sergeev
2008-05-29  6:03                       ` Takashi Iwai
2008-05-29 17:07                         ` Stas Sergeev
2008-06-02  9:36                           ` Takashi Iwai
2008-08-21  8:06                 ` Stas Sergeev
2008-08-21  9:06                   ` Takashi Iwai [this message]
2008-08-21 10:25                     ` Stas Sergeev
2008-10-20 13:05                       ` Takashi Iwai
2008-10-20 21:51                         ` Stas Sergeev
2008-10-21  6:27                           ` Takashi Iwai
2008-10-21  7:08                             ` Stas Sergeev
2008-10-21  7:16                               ` 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=s5hej4ibuus.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=stsp@aknet.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox