1. 07 Mar, 2016 6 commits
  2. 04 Mar, 2016 8 commits
  3. 03 Mar, 2016 1 commit
  4. 02 Mar, 2016 1 commit
  5. 01 Mar, 2016 3 commits
  6. 29 Feb, 2016 6 commits
  7. 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
  8. 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
  9. 25 Feb, 2016 3 commits
  10. 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