summaryrefslogtreecommitdiff
path: root/sound/firewire/bebob/bebob.c
diff options
context:
space:
mode:
authorTakashi Sakamoto <o-takashi@sakamocchi.jp>2016-02-20 10:18:56 +0300
committerTakashi Iwai <tiwai@suse.de>2016-02-20 17:45:15 +0300
commit14a37ac1bf8a2ba9b19032195c371c7b0857ca87 (patch)
treee1673eef6a4a96767b06782aae13932a4130f701 /sound/firewire/bebob/bebob.c
parent3184270ec188a70df555ab08bca70c0e61704205 (diff)
downloadlinux-14a37ac1bf8a2ba9b19032195c371c7b0857ca87.tar.xz
ALSA: bebob: simplify bus-reset handling
At bus-reset, DM1000/DM1100/DM1500 chipsets transfer packets with discontinuous value in 'dbc' field of CIP header. In this case, packet streaming layer in firewire-lib module stops streaming and set XRUN to PCM substream. In ALSA, PCM applications are notified the XRUN status by the return value of ALSA PCM interface. They can recover this state by executing snd_pcm_prepare(), then PCM drivers' prepare handler is called, and start new PCM substream. For ALSA BeBoB driver, the handler establishes new connections and start new AMDTP streaming. Unfortunately, neither the PCM applications nor the driver know the reason of XRUN. The driver gets to know the reason when update handler is called by IEEE 1394 bus driver. As long as I tested, the order of below events are not fixed: * Detecting packet discontinuity in tasklet context of OHCI 1394 driver * Calling prepare handler in process context of ALSA PCM application * Calling update handler in kthread context of IEEE 1394 bus driver The unpredictable order is disadvantage for the driver to be compliant to CMP. In IEC 61883-1, new CMP establish operations should be done 1 sec (isoc_resource_delay) after bus-reset. Within 1 sec, CMP restore operations are allowed. For this reason, in former commit ('b6bc812327aa: ALSA: bebob/firewire-lib: Add a quirk for discontinuity at bus reset'), the process context is forced to wait for executing update handler. The process context wait for bus-reset up to 1 sec. This commit solves the issue, while causes more disadvantages. For PCM applications, calling snd_pcm_prepare() for recovering XRUN state takes more time and the driver got a bit complicated code, while the recovery is not always successful. As long as I tested, DM1000/DM1100/DM1500 and BeBoB firmware can allow drivers to establish new connections just after bus reset. Furthermore, any FCP transactions are handled correctly. Therefore, the driver don't need to wait for bus reset handler for starting new streaming. This commit removes the codes to reduce maintenance cost. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'sound/firewire/bebob/bebob.c')
-rw-r--r--sound/firewire/bebob/bebob.c7
1 files changed, 3 insertions, 4 deletions
diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c
index 091290d1f3ea..671179eaff1e 100644
--- a/sound/firewire/bebob/bebob.c
+++ b/sound/firewire/bebob/bebob.c
@@ -309,7 +309,10 @@ bebob_update(struct fw_unit *unit)
return;
fcp_bus_reset(bebob->unit);
+
+ mutex_lock(&bebob->mutex);
snd_bebob_stream_update_duplex(bebob);
+ mutex_unlock(&bebob->mutex);
if (bebob->deferred_registration) {
if (snd_card_register(bebob->card) < 0) {
@@ -327,10 +330,6 @@ static void bebob_remove(struct fw_unit *unit)
if (bebob == NULL)
return;
- /* Awake bus-reset waiters. */
- if (!completion_done(&bebob->bus_reset))
- complete_all(&bebob->bus_reset);
-
/* No need to wait for releasing card object in this context. */
snd_card_free_when_closed(bebob->card);
}