From: Takashi Iwai <tiwai@suse.de>
To: "Sridharan, Ranjani" <ranjani.sridharan@intel.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH 7/8] ALSA: pcm: Add card sync_irq field
Date: Mon, 18 Nov 2019 20:49:29 +0100 [thread overview]
Message-ID: <s5hpnhpyng6.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAFQqKeWgqHwrCSSbLrkuCHkBww2g4dsBcF93SDN_ZK_-KSe5tg@mail.gmail.com>
On Mon, 18 Nov 2019 20:20:41 +0100,
Sridharan, Ranjani wrote:
>
> On Mon, Nov 18, 2019 at 10:54 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Mon, 18 Nov 2019 17:38:49 +0100,
> Pierre-Louis Bossart wrote:
> >
> >
> >
> > On 11/17/19 2:53 AM, Takashi Iwai wrote:
> > > Many PCI and other drivers performs snd_pcm_period_elapsed() simply in
> > > its interrupt handler, so the sync_stop operation is just to call
> > > synchronize_irq(). Instead of putting this call multiple times,
> > > introduce the common card->sync_irq field. When this field is set,
> > > PCM core performs synchronize_irq() for sync-stop operation. Each
> > > driver just needs to copy its local IRQ number to card->sync_irq, and
> > > that's all we need.
> >
> > Maybe a red-herring or complete non-sense, but I wonder if this is
> > going to get in the way of Ranjani's multi-client work, where we could
> > have multiple cards created but with a single IRQ handled by the
> > parent PCI device?
> >
> > Ranjani, you may want to double-check this and chime in, thanks!
>
> The synchronize_irq() is fairly safe to call multiple times, and I
> don't think any problem by invoking it for multi-clients sharing the
> same IRQ. For example, Digigram miXart driver creates multiple card
> objects from a single PCI entry, and I already thought of that
> possibility; they set the same card->sync_irq value to all card
> objects, which eventually will call synchronize_irq() multiple times.
> From the performance POV, this shouldn't be a big problem, because
> the place calling this is only at hw_params, prepare and hw_free,
> neither are hot-path.
>
> Thanks for the clarification, Takashi. But just wondering how would one pass
> on the sync_irq when the snd_card is created? Typically in the case of the
> Intel platforms, the card->dev points to the platform device for the machine
> driver that registers the card and the PCI device is the parent of the machine
> drv platform device.
It's completely up to the driver implementation :)
You can implement the own sync_stop ops if that's easier, too.
In general, the driver can set up card->sync_irq when the
request_irq() or its variant is called.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-11-18 19:50 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-17 8:53 [alsa-devel] [PATCH 0/8] ALSA: pcm: API cleanups and extensions Takashi Iwai
2019-11-17 8:53 ` [alsa-devel] [PATCH 1/8] ALSA: pcm: Introduce managed buffer allocation mode Takashi Iwai
2019-11-18 16:24 ` Pierre-Louis Bossart
2019-11-18 18:46 ` Takashi Iwai
2019-11-17 8:53 ` [alsa-devel] [PATCH 2/8] ALSA: docs: Update for " Takashi Iwai
2019-11-17 8:53 ` [alsa-devel] [PATCH 3/8] ALSA: pcm: Allow NULL ioctl ops Takashi Iwai
2019-11-17 8:53 ` [alsa-devel] [PATCH 4/8] ALSA: docs: Update document about the default PCM " Takashi Iwai
2019-11-17 8:53 ` [alsa-devel] [PATCH 5/8] ALSA: pcm: Move PCM_RUNTIME_CHECK() macro into local header Takashi Iwai
2019-11-17 9:42 ` kbuild test robot
2019-11-17 9:42 ` kbuild test robot
2019-11-17 10:05 ` Takashi Iwai
2019-11-17 10:28 ` kbuild test robot
2019-11-17 10:28 ` kbuild test robot
2019-11-17 8:53 ` [alsa-devel] [PATCH 6/8] ALSA: pcm: Add the support for sync-stop operation Takashi Iwai
2019-11-18 16:33 ` Pierre-Louis Bossart
2019-11-18 18:47 ` Takashi Iwai
2019-11-17 8:53 ` [alsa-devel] [PATCH 7/8] ALSA: pcm: Add card sync_irq field Takashi Iwai
2019-11-18 16:38 ` Pierre-Louis Bossart
2019-11-18 18:52 ` Takashi Iwai
2019-11-18 19:20 ` Sridharan, Ranjani
2019-11-18 19:49 ` Takashi Iwai [this message]
2019-11-18 19:55 ` Sridharan, Ranjani
2019-11-18 20:40 ` Takashi Iwai
2019-11-18 23:47 ` Ranjani Sridharan
2019-11-19 6:44 ` Takashi Iwai
2019-11-19 7:40 ` Ranjani Sridharan
2019-11-19 8:24 ` Takashi Iwai
2019-11-19 9:39 ` Takashi Iwai
2019-11-19 16:36 ` Ranjani Sridharan
2019-11-19 21:27 ` Takashi Iwai
2019-11-19 21:43 ` Sridharan, Ranjani
2019-11-21 19:22 ` Sridharan, Ranjani
2019-11-21 20:34 ` Takashi Iwai
2019-11-21 20:46 ` Sridharan, Ranjani
2019-11-21 21:13 ` Takashi Iwai
2019-11-21 21:17 ` Sridharan, Ranjani
2019-11-21 21:28 ` Takashi Iwai
2019-11-21 21:45 ` Sridharan, Ranjani
2019-11-22 4:08 ` Jie, Yang
2019-11-17 8:53 ` [alsa-devel] [PATCH 8/8] ALSA: docs: Update about the new PCM sync_stop ops 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=s5hpnhpyng6.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@intel.com \
--cc=ranjani.sridharan@linux.intel.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.