ALSA: bebob: expand sleep just after breaking connections for protocol version 1
authorTakashi Sakamoto <o-takashi@sakamocchi.jp>
Fri, 1 Nov 2019 13:13:21 +0000 (22:13 +0900)
committerTakashi Iwai <tiwai@suse.de>
Sat, 2 Nov 2019 07:49:50 +0000 (08:49 +0100)
As long as I investigated, some devices with BeBoB protocol version 1
can be freezed during several hundreds milliseconds after breaking
connections. When accessing during the freezed time, any transaction
is corrupted. In the worst case, the device is going to reboot.

I can see this issue in:
 * Roland FA-66
 * M-Audio FireWire Solo

This commit expands sleep just after breaking connections to avoid
the freezed time as much as possible. I note that the freeze/reboot
behaviour is similar to below models:
 * Focusrite Saffire Pro 10 I/O
 * Focusrite Saffire Pro 26 I/O

The above models certainly reboot after breaking connections.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/firewire/bebob/bebob_stream.c

index f7f0db5..1b264d0 100644 (file)
@@ -415,15 +415,16 @@ static int make_both_connections(struct snd_bebob *bebob)
        return 0;
 }
 
-static void
-break_both_connections(struct snd_bebob *bebob)
+static void break_both_connections(struct snd_bebob *bebob)
 {
        cmp_connection_break(&bebob->in_conn);
        cmp_connection_break(&bebob->out_conn);
 
-       /* These models seems to be in transition state for a longer time. */
-       if (bebob->maudio_special_quirk != NULL)
-               msleep(200);
+       // These models seem to be in transition state for a longer time. When
+       // accessing in the state, any transactions is corrupted. In the worst
+       // case, the device is going to reboot.
+       if (bebob->version < 2)
+               msleep(600);
 }
 
 static int