All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, clemens@ladisch.de,
	ffado-devel@lists.sf.net
Subject: Re: [PATCH 5/8] ALSA: dice: purge generating channel cache
Date: Fri, 20 Nov 2015 01:15:53 +0100	[thread overview]
Message-ID: <20151120011553.698903a2@kant> (raw)
In-Reply-To: <1447579536-4459-6-git-send-email-o-takashi@sakamocchi.jp>

On Nov 15 Takashi Sakamoto wrote:
> Dice hardware design doesn't allow drivers to read supported combination
> between sampling transfer frequencies and the number of Multi bit linear
> audio data channels. According to the design, ALSA dice driver changes
> current sampling transfer frequency to generate the cache of combinations
> at probing processing.
> 
> Although, this idea is worse because ALSA dice driver cannot handle bus
> reset when processing driver's probe callback. The callbacks of drivers
> for units on IEEE 1394 bus are serialized. For example, when processing
> .probe callback in workqueue context, any other processing such as
> .update is not executed. As a result, when processing probe callback,
> the driver cannot handle bus reset.
[...]

It is natural that .probe(), .update(), .remove() driver methods are not
reentrant.  We must not call an .update() or .remove() for a
device + driver pair whose .probe() has not yet returned successfully.

Therefore, procedures which require bus reset handling should not be
implemented within the .probe().

For example, the IEEE 1394 storage initiator driver firewire-sbp2 performs
SBP-2 login and the initial SCSI INQUIRY in an own deferred execution
context, not inside .probe().  If a bus reset happens in the middle of the
SBP-2 login transaction or in the middle of the SCSI INQUIRY transaction,
that transaction is aborted and rescheduled.

I am only mentioning this as a general remark, not as a direct comment on
this patch or on the snd-dice driver even.  Perhaps similar deferred
execution in a separate execution context is something suitable for a DICE
driver, perhaps not; I can't say as I am entirely unfamiliar with the
protocol.

> Unfortunately, most Dice based models generate bus reset several times
> after powering on.
[...]

Besides, if there are more devices on the bus, bus resets could be
generated by those other nodes too (for example if they boot at the
same time as the audio device does).
-- 
Stefan Richter
-=====-===== =-== =-=--
http://arcgraph.de/sr/

  reply	other threads:[~2015-11-20  0:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-15  9:25 [RFC][PATCH 0/8] ALSA: dice: constrain PCM substreams to current sampling transfer frequency Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 1/8] ALSA: dice: limit " Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 2/8] ALSA: dice: limit stream " Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 3/8] ALSA: dice: add MIDI ports according to current number of MIDI substreams Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 4/8] ALSA: dice: get the number of MBLA data channel at opening PCM substream Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 5/8] ALSA: dice: purge generating channel cache Takashi Sakamoto
2015-11-20  0:15   ` Stefan Richter [this message]
2015-11-15  9:25 ` [PATCH 6/8] ALSA: dice: ensure phase lock before starting streaming Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 7/8] ALSA: dice: expand timeout to wait for Dice notification Takashi Sakamoto
2015-11-15  9:25 ` [PATCH 8/8] ALSA: dice: wait for ensuring phase lock Takashi Sakamoto
2015-11-18 14:13 ` [RFC][PATCH 0/8] ALSA: dice: constrain PCM substreams to current sampling transfer frequency Takashi Iwai
2015-11-19  3:34   ` Takashi Sakamoto
2015-11-19 10:19     ` Takashi Iwai
2015-11-20  4:11       ` Takashi Sakamoto
2015-11-20  9:25         ` Takashi Iwai
2015-11-20 11:19           ` Takashi Sakamoto
2015-11-20 11:29             ` Takashi Iwai
2015-11-21  0:29               ` Takashi Sakamoto
2015-11-21  9:46                 ` Takashi Iwai
2015-11-24 15:04                   ` Takashi Sakamoto
2015-11-24 15:33                     ` Takashi Iwai
2015-11-25  0:08                       ` Takashi Sakamoto

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=20151120011553.698903a2@kant \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=ffado-devel@lists.sf.net \
    --cc=o-takashi@sakamocchi.jp \
    --cc=tiwai@suse.de \
    /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.