1. 04 Mar, 2016 4 commits
  2. 03 Mar, 2016 1 commit
  3. 02 Mar, 2016 1 commit
  4. 01 Mar, 2016 3 commits
  5. 29 Feb, 2016 6 commits
  6. 28 Feb, 2016 7 commits
    • Takashi Iwai's avatar
      ALSA: timer: Fix ioctls for X32 ABI · b24e7ad1
      Takashi Iwai authored
      X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
      incompatible with IA32.  This results in NOTTY error when the ioctl is
      issued.
      
      Meanwhile, this struct in X32 is essentially identical with the one in
      X86-64, so we can just bypassing to the existing code for this
      specific compat ioctl.
      
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b24e7ad1
    • Takashi Iwai's avatar
      ALSA: timer: Fix broken compat timer user status ioctl · 3a72494a
      Takashi Iwai authored
      The timer user status compat ioctl returned the bogus struct used for
      64bit architectures instead of the 32bit one.  This patch addresses
      it to return the proper struct.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3a72494a
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix ioctls X32 ABI · 2251fbbc
      Takashi Iwai authored
      Like the previous fixes for ctl and PCM, we need a fix for
      incompatible X32 ABI regarding the rawmidi: namely, struct
      snd_rawmidi_status has the timespec, and the size and the alignment on
      X32 differ from IA32.
      
      This patch fixes the incompatible ioctl for X32.
      
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2251fbbc
    • Takashi Iwai's avatar
      ALSA: rawmidi: Use comapt_put_timespec() · dd7e3f80
      Takashi Iwai authored
      Instead of open-coding, use the existing helper to copy a 32bit
      timespec from/to 64bit.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dd7e3f80
    • Takashi Iwai's avatar
      ALSA: pcm: Fix ioctls for X32 ABI · 513ace79
      Takashi Iwai authored
      X32 ABI uses the 64bit timespec in addition to 64bit alignment of
      64bit values.  This leads to incompatibilities in some PCM ioctls
      involved with snd_pcm_channel_info, snd_pcm_status and
      snd_pcm_sync_ptr structs.  Fix the PCM compat ABI for these ioctls
      like the previous commit for ctl API.
      Reported-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      513ace79
    • Takashi Iwai's avatar
      ALSA: ctl: Fix ioctls for X32 ABI · 6236d8bb
      Takashi Iwai authored
      The X32 ABI takes the same alignment like x86-64, and this may result
      in the incompatible struct size from ia32.  Unfortunately, we hit this
      in some control ABI: struct snd_ctl_elem_value differs between them
      due to the position of 64bit variable array.  This ends up with the
      unknown ioctl (ENOTTY) error.
      
      The fix is to add the compat entries for the new aligned struct.
      Reported-and-tested-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6236d8bb
    • Takashi Sakamoto's avatar
      ALSA: dice: drop duplex streams synchronization to transfer own time stamps · 1387e3ea
      Takashi Sakamoto authored
      This commit drops implementation of duplex streams synchronization
      from ALSA dice driver, due to a reason of hardware design. This patch
      allows dice-based units to generate sounds correctly when isochronous
      packet streaming starts at first time.
      
      In IEC 61883-6:2005, CIP packetization layer for AM824 data format
      utilizes the value of SYT field in CIP header of received packet for
      a reference to phase lock loop. Figure 3 in clause 4.3 describes it.
      The value is an offset from cycle_time field of every cycle start packet
      from cycle master on IEEE 1394 bus. The time calculated with these two
      fields is called as 'presentation timestamp' which represents the time
      to play data included in the packet.
      
      Although, this idea includes some problems due to accuracy of timekeep in
      cycle master, accuracy of transmission of cycle start packet on the bus
      with the other units, accuracy of sampling clock in data transmitter side
      and accuracy of replay in data receiver side. In most case, these
      accuracies somewhat worse because there's no such ideal hardwares in this
      world.
      
      For the issues, ASICs for Dice include Jitter Elimination Technologies
      (JET) PLL. The PLL can handle several sources of clock and compensate it
      with high-precision internal clock source. The sequence of value in syt
      field of received AMDTP packets is one of the sources, therefore
      transmitters on IEEE 1394 bus should transfer it.
      
      On the other hand, current ALSA dice driver is programmed with a mode of
      duplex streams with synchronization. In this mode, the driver outputs
      packets after some incoming packets are handled, to re-use the value of
      SYT field in incoming packets to the value for outgoing packets. This mode
      is enabled when source signal of sampling clock is set to internal, and
      this is a major use case. Thus, in most cases, the unit receives no packets
      during a short time after packet streaming starts.
      
      As long as I experienced, this causes the units to generate no sounds at
      first time to receive packets. This issue occurs only with Dice II. I guess
      this is due to a quirk of the PLL. In short, the PLL cannot generate firm
      signals to ADCs/DACs or the other ICs when no packets are received in the
      beginning of packet streaming. While, on second time or later, the unit
      generates sound correctly. I guess that starting packet streaming at first
      time sets the PLL correctly.
      
      Well, still based on my hypothesis and no way to prove it, this commit
      drops duplex streams synchronization from this driver. At least, the PLL
      requires the sequence of value in SYT field of received AMDTP packets as
      one of source of clock signals with internal clock source.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1387e3ea
  7. 26 Feb, 2016 3 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · d61b04f8
      Takashi Iwai authored
      d61b04f8
    • Ville Syrjälä's avatar
      ALSA: hda - Autosuspend controller after probe even if codecs are already suspended · 30ff5957
      Ville Syrjälä authored
      azx_probe_continue() uses pm_runtime_put_noidle() to drop the rpm
      usage_count, which means that if it's the last reference the
      autosuspend of the controller won't actually happen. So if the codecs
      autosuspend before the azx_probe_continue() drops the last
      reference we'll fail to autosuspend the controller. This does happen
      in practice, but not every time. As can be seen in [1] the controller
      autosuspend attempt fails due to the usage_count when suspending the
      codecs. A bit later we see the the contoller usage_count dropping to
      zero without further attempts at autosuspend.
      
      Fix the problem by using pm_runtime_put_autosuspend() instead, which
      will kick off the autosuspend of the controller even if the codecs
      are already asleep. As can be seen in [2] the controller autosuspend
      still fails while suspending the codecs, but later on we see another
      autosuspend attempt after dropping the usage_count to 0.
      
      I was also a bit worried that there might still be a race between the
      controller autosuspend and the rest of the code in azx_probe_continue().
      So I also tried replacing the the put_noidle() with put_sync_suspend().
      No explosions occurred, so I'm somewhat satisfied that there are no
      serious problems in this area.
      
      [1]
       kworker/1:2-122   [001] ....    63.661310: __pm_runtime_suspend: hdaudioC0D0 usage_count 0
       kworker/1:2-122   [001] d..2    63.661316: rpm_suspend: hdaudioC0D0 flags-d cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/1:2-122   [001] d..1    63.661317: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
       kworker/1:2-122   [001] d..2    63.661332: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
       kworker/1:1-72    [001] d..2    63.661543: rpm_suspend: hdaudioC0D0 flags-a cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/1:1-72    [001] d..1    63.661544: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
       kworker/1:1-72    [001] ....    63.661545: hda_codec_runtime_suspend: hdaudioC0D0 suspend
       kworker/1:1-72    [001] d..2    63.661614: rpm_idle: 0000:00:03.0 flags-1 cnt-1  dep-0  auto-1 p-0 irq-0 child-0
       kworker/1:1-72    [001] d..1    63.661615: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1
       kworker/1:1-72    [001] d..1    63.661615: rpm_check_suspend_allowed: 0000:00:03.0 retval -11
       kworker/1:1-72    [001] d..2    63.661616: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11
       kworker/1:1-72    [001] d..2    63.661616: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
       kworker/1:2-122   [001] d..2    63.664834: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/1:2-122   [001] d..1    63.664835: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
       kworker/1:2-122   [001] d..2    63.664836: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
       kworker/1:2-122   [001] d..2    63.664841: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/1:2-122   [001] d..1    63.664841: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
       kworker/1:2-122   [001] d..2    63.664841: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
       kworker/1:2-122   [001] ....    63.664842: azx_probe_continue: 0000:00:03.0 usage_count=0
      
      [2]
       kworker/0:0-4     [000] ....    50.354567: __pm_runtime_suspend: hdaudioC0D0 usage_count 0
       kworker/0:0-4     [000] d..2    50.354574: rpm_suspend: hdaudioC0D0 flags-d cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:0-4     [000] d..1    50.354575: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
       kworker/0:0-4     [000] d..2    50.354589: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
       kworker/0:2-135   [000] d..2    50.354809: rpm_suspend: hdaudioC0D0 flags-a cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:2-135   [000] d..1    50.354810: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
       kworker/0:2-135   [000] ....    50.354816: hda_codec_runtime_suspend: hdaudioC0D0 suspend
       kworker/0:2-135   [000] d..2    50.354908: rpm_idle: 0000:00:03.0 flags-1 cnt-1  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:2-135   [000] d..1    50.354909: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1
       kworker/0:2-135   [000] d..1    50.354909: rpm_check_suspend_allowed: 0000:00:03.0 retval -11
       kworker/0:2-135   [000] d..2    50.354909: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11
       kworker/0:2-135   [000] d..2    50.354910: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
       kworker/0:0-4     [000] d..2    50.373791: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:0-4     [000] d..1    50.373792: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
       kworker/0:0-4     [000] d..2    50.373793: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
       kworker/0:0-4     [000] d..2    50.373797: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:0-4     [000] d..1    50.373798: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
       kworker/0:0-4     [000] d..2    50.373798: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
       kworker/0:0-4     [000] ....    50.373799: __pm_runtime_suspend: 0000:00:03.0 usage_count 0
       kworker/0:0-4     [000] d..2    50.373800: rpm_suspend: 0000:00:03.0 flags-d cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:0-4     [000] d..1    50.373800: rpm_check_suspend_allowed: 0000:00:03.0 retval 0
       kworker/0:0-4     [000] d..2    50.373803: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0
       kworker/0:0-4     [000] d..2    50.385164: rpm_suspend: 0000:00:03.0 flags-a cnt-0  dep-0  auto-1 p-0 irq-0 child-0
       kworker/0:0-4     [000] d..1    50.385165: rpm_check_suspend_allowed: 0000:00:03.0 retval 0
       kworker/0:0-4     [000] ....    50.385174: azx_runtime_suspend: 0000:00:03.0 azx suspend releaseing power well
       kworker/0:0-4     [000] ....    50.385179: azx_runtime_suspend: 0000:00:03.0 azx suspend
       kworker/0:0-4     [000] d..2    50.386872: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      30ff5957
    • Takashi Iwai's avatar
      ALSA: hda - Loop interrupt handling until really cleared · 473f4145
      Takashi Iwai authored
      Currently the interrupt handler of HD-audio driver assumes that no irq
      update is needed while processing the irq.  But in reality, it has
      been confirmed that the HW irq is issued even during the irq
      handling.  Since we clear the irq status at the beginning, process the
      interrupt, then exits from the handler, the lately issued interrupt is
      left untouched without being properly processed.
      
      This patch changes the interrupt handler code to loop over the
      check-and-process.  The handler tries repeatedly as long as the IRQ
      status are turned on, and either stream or CORB/RIRB is handled.
      
      For checking the stream handling, snd_hdac_bus_handle_stream_irq()
      returns a value indicating the stream indices bits.  Other than that,
      the change is only in the irq handler itself.
      Reported-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      473f4145
  8. 25 Feb, 2016 3 commits
  9. 24 Feb, 2016 2 commits
    • Takashi Sakamoto's avatar
      ALSA: oxfw: discontinue MIDI substream for scs1x at transaction failure · 956dea9e
      Takashi Sakamoto authored
      With a previous commit, ALSA oxfw driver retries transferring MIDI
      messages at transaction failure for scs1x. On the other hand, there're
      fatal transaction error. Then, no MIDI messages reach to the unit anymore.
      In this case, MIDI substream should be terminated.
      
      This commit stops MIDI transmission after the fatal error occurs.
      Unfortunately, unlike ALSA PCM functionality, ALSA rawmidi core has no
      feature to discontinue MIDI substream runtime in kernel side, thus this
      commit just stops MIDI transmission without notifying it to userspace.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      956dea9e
    • Takashi Sakamoto's avatar
      ALSA: oxfw: retry MIDI transferring for scs1x at transaction failure · b4c23ab1
      Takashi Sakamoto authored
      Currently, ALSA oxfw driver has a TODO to retry MIDI transferring
      at transaction failure.
      
      This commit achieves it. Current implementation uses snd_rawmidi_transmit()
      to transfer messages, thus the target MIDI messages are not in buffer when
      transaction failure is detected. Although we cannot use a pair of
      snd_rawmidi_transmit_peek() and snd_ramwidi_transmit_ack(), the
      messages are still in scs1x specific structure and the data is available
      for retries.
      
      This commit adds a member to the structure for the length of buffered
      messages, and uses the value again at retries.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b4c23ab1
  10. 23 Feb, 2016 2 commits
    • Libin Yang's avatar
      ALSA: hda - hdmi eld control created based on pcm · fb087eaa
      Libin Yang authored
      eld control is created based on pcm now.
      When monitor is connected, eld control will be bound to
      pin automatically.
      Signed-off-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fb087eaa
    • Takashi Iwai's avatar
      ALSA: jack: Allow building the jack layer without input device · fe0d128c
      Takashi Iwai authored
      Since the recent integration of kctl jack and input jack layers, we
      can basically build the jack layer even without input devices.  That
      is, the jack layer itself can be built with conditional to enable the
      input device support or not, while the users may enable always
      CONFIG_SND_JACK unconditionally.
      
      For achieving it, this patch changes the following:
      - A new Kconfig, CONFIG_SND_JACK_INPUT_DEV, was introduced to indicate
        whether the jack layer supports the input device,
      - A few items in snd_jack struct and relevant codes are conditionally
        built upon CONFIG_SND_JACK_INPUT_DEV,
      - The users of CONFIG_SND_JACK drop the messy dependency on
        CONFIG_INPUT.
      
      This change also automagically fixes a potential bug in HD-audio
      driver Arnd reported, where the NULL or uninitialized jack instance is
      dereferenced.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fe0d128c
  11. 22 Feb, 2016 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Apply clock gate workaround to Skylake, too · 7e31a015
      Takashi Iwai authored
      Some Skylake machines show the codec probe errors in certain
      situations, e.g. HP Z240 desktop fails to probe the onboard Realtek
      codec at reloading the snd-hda-intel module like:
        snd_hda_intel 0000:00:1f.3: spurious response 0x200:0x2, last cmd=0x000000
        snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: lastcmd=0x000f0000
        snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
        snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
        hdaudio hdaudioC0D2: no AFG or MFG node found
        snd_hda_intel 0000:00:1f.3: no codecs initialized
      
      Also, HP G470 G3 suffers from the similar problem, as reported in
      bugzilla below.  On this machine, the codec probe error appears even
      at a fresh boot.
      
      As Libin suggested, the same workaround used for Broxton in the commit
      [6639484d: ALSA: hda - disable dynamic clock gating on Broxton
       before reset] can be applied for Skylake in order to fix this problem.
      The Intel HW team also confirmed that this is needed for SKL.
      
      This patch makes the workaround applied to both SKL and BXT
      platforms.  The referred macros are moved and one superfluous macro
      (IS_BROXTON()) is another one (IS_BXT()) as well.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112731Suggested-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7e31a015
    • Sudip Mukherjee's avatar
      ALSA: mts64: use new parport device model · 94a57350
      Sudip Mukherjee authored
      Modify mts64 driver to use the new parallel port device model.
      The advantage of using the device model is that the driver gets binded
      to the hardware, we get the feature of hotplug, we can bind/unbind the
      driver at runtime.
      The changes are in the way the driver gets registered with the parallel
      port subsystem and the temporary device to probe mts64 card is removed
      and mts64_probe() is used in the probe callback.
      Signed-off-by: default avatarSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      94a57350
  12. 21 Feb, 2016 1 commit
  13. 20 Feb, 2016 5 commits
    • Takashi Sakamoto's avatar
      ALSA: fireworks: serialize transactions to update connections at bus reset · 99d73559
      Takashi Sakamoto authored
      In IEC 61883-1, at bus-reset, applications can continue isochronous
      streaming by updating connections. In ALSA fireworks driver, the
      operation is executed in 'update' handler for bus driver.
      
      The connection resources are also changed in process contexts of PCM/MIDI
      applications. Therefore, bus-reset handling has race condition
      against connection. Current ALSA fireworks driver has a bug for the
      condition.
      
      This commit fixes the bug, by expand critical section with mutex. As a
      result, connection updating operation in bus-reset handler and connection
      changing operation in process context are serialized.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      99d73559
    • Takashi Sakamoto's avatar
      ALSA: bebob: give up updating streams at bus reset handler · 3800e6f9
      Takashi Sakamoto authored
      DM1000/DM1100/DM1500 chipsets transfer packets with discontinue value in
      'dbc' field of CIP header. For ALSA bebob driver, this makes its bus-reset
      handler meaningless, because the discontinuity is detected quite earlier
      than executing the handler.
      
      This commit gives up updating streams at the bus reset handler.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3800e6f9
    • Takashi Sakamoto's avatar
      ALSA: bebob: change type of substream counter from atomic_t to unsigned int · 4fd6c6c7
      Takashi Sakamoto authored
      The counter is incremented/decremented in critical section protected with
      mutex. Therefore, no need to use atomic_t.
      
      This commit changes the type to unsigned int.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4fd6c6c7
    • Takashi Sakamoto's avatar
      ALSA: bebob: move mutex from function callee to callers · 2a71e701
      Takashi Sakamoto authored
      Currently, critical section is protected by mutex in functions of
      fireworks_stream.c. Callers increments/decrements substreams counter
      before calling the functions. Moving mutex to the callers code allows
      to change type of the substream counter from atomic_t to unsigned int.
      
      This commit is a preparation for obsoleting usage of atomic_t for
      substream counter.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2a71e701
    • Takashi Sakamoto's avatar
      ALSA: bebob: simplify bus-reset handling · 14a37ac1
      Takashi Sakamoto authored
      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 ('b6bc8123:
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      14a37ac1