1. 14 Mar, 2016 2 commits
  2. 11 Mar, 2016 1 commit
  3. 10 Mar, 2016 5 commits
  4. 09 Mar, 2016 4 commits
    • Takashi Sakamoto's avatar
      ALSA: dice: force to add two pcm devices for listed models · 7cafc65b
      Takashi Sakamoto authored
      Some models reduce the number of available isochronous streams for higher
      sampling transfer frequency. Such models bring an issue about how to add
      PCM substreams. When at lower sampling transfer frequency, the
      models reports whole available streams, thus this driver can add enough
      number of PCM substreams at probing time. On the other hand, at higher
      sampling transfer frequency, this driver can just add reduced number of
      PCM substreams. After probed, even if the sampling transfer frequency is
      changed to lower rate, fewer PCM substreams are actually available. This
      is inconvenience.
      
      For the reason, this commit adds a list so that this driver assume models
      on the list to have two pairs of PCM substreams. This list keeps the name
      of model in which the number of available streams differs depending on
      sampling transfer frequency.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7cafc65b
    • Takashi Sakamoto's avatar
      ALSA: dice: handle several PCM substreams when any isochronous streams are available · 4bdc495c
      Takashi Sakamoto authored
      In former commits, ALSA dice driver can handle available isochronous
      streams. This commit adds support for several PCM substreams on the
      streams.
      
      The additional PCM substreams are available via another ALSA PCM character
      devices so that one ALSA PCM application can handle them without cumbersome
      operations. For example, two PCM substreams are available on each stream,
      two ALSA character devices are added for them. In configuration space of
      alsa-lib, it's represented with 'hw:0,0' and 'hw:0,1'.
      
      The PCM substreams are constraint to parameters of the corresponding
      streams. If the PCM substreams are unavailable for some reasons,
      open(2) to ALSA PCM character device returns error and reports ENXIO.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4bdc495c
    • Takashi Sakamoto's avatar
      ALSA: dice: handle whole available isochronous streams · 436b5abe
      Takashi Sakamoto authored
      This commit enables ALSA dice driver to handle whole available streams.
      
      In Dice, certain registers represent the number of available streams at
      current sampling transfer frequency for both directions. The parameters
      of each stream are represented in a block of register. This block is
      aligned sequentially. These streams start simultaneously by writing
      enable bit to a register.
      
      This commit operates these registers when starting/stopping streams.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      436b5abe
    • Takashi Sakamoto's avatar
      ALSA: dice: have two sets of isochronous resources/streams · 8ae25b76
      Takashi Sakamoto authored
      Currently ALSA dice driver handles a pair of isochronous resources for
      IEC 61883-1/6 packet streaming. While, according to some documents about
      ASICs named as 'Dice', several isochronous streams are available.
      
      Here, I start to describe ASICs produced under 'Dice' name.
       * Dice II (designed by wavefront semiconductor, including TCAT's IP)
         * STD (with limited functionality of DTCP)
         * CP  (with full functionality of DTCP)
       * TCD2210/2210-E (so-called 'Dice Mini')
       * TCD2220/2220-E (so-called 'Dice Jr.')
       * TCD3070-CH (so-called 'Dice III')
      
      Some documents are public and we can see hardware design of them. We can
      find some articles about hardware internal register definitions
      (not registers exported to IEEE 1394 bus).
      
      * DICE II User Guide
        * http://www.tctechnologies.tc/archive/downloads/dice_ii_user_guide.pdf
          * 6.1 AVS Audio Receivers
            * Table 6.1: AVS Audio Receiver Memory Map
              * ARX1-ARX4
          * 6.2 AVS Audio Transmitters
            * Table 6.2: AVS Audio Transmitter Memory Map
              * ATX1, ATX2
      * TCD22xx User Guide
        * http://www.tctechnologies.tc/downloads/tcd22xx_user_guide.pdf
          * 6.1 AVS Audio Receivers
            * Table 66: AVS Audio Receiver Memory Map
              * ARX1, ARX2
          * 6/2 AVS Audio Transmitters
            * Table 67: AVS Audio Transmitter Memory Map
              * ATX1, ATX2
      * DICE III
        * http://www.tctechnologies.tc/downloads/TCD3070-CH.pdf
          * Dual stream 63 channel transmitter/receiver
      
      For Dice II and TCD22xx series, maximum 16 data channels are transferred in
      an AMDTP packet, while for Dice III, maximum 32 data channels are
      transferred.
      
      According to the design of the series of these ASICs, this commit allows
      this driver to handle additional set of isochronous resources. For
      practical reason, two pair of isochronous resources are added. As of this
      commit, this driver still use a pair of the first isochronous resources.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8ae25b76
  5. 08 Mar, 2016 3 commits
    • Martin Koegler's avatar
      ALSA: seq: Provide card number / PID via sequencer client info · a1ce94d0
      Martin Koegler authored
      rawmidi devices expose the card number via IOCTLs, which allows to
      find the corresponding device in sysfs.
      
      The sequencer provides no identifing data. Chromium works around this
      issue by scanning rawmidi as well as sequencer devices and matching
      them by using assumtions, how the kernel register sequencer devices.
      
      This changes adds support for exposing the card number for kernel clients
      as well as the PID for user client.
      
      The minor of the API version is changed to distinguish between the zero
      initialised reserved field and card number 0.
      
      [minor coding style fixes by tiwai]
      Signed-off-by: default avatarMartin Koegler <martin.koegler@chello.at>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a1ce94d0
    • Takashi Iwai's avatar
      Merge branch 'topic/hda' into for-next · 56d94d70
      Takashi Iwai authored
      56d94d70
    • Takashi Iwai's avatar
      ALSA: hda - Fix unexpected resume through regmap code path · fc4f000b
      Takashi Iwai authored
      HD-audio driver has a mechanism to trigger the runtime resume
      automatically at accessing the verbs.  This auto-resume, however,
      causes the mutex deadlock when invoked from the regmap handler since
      the regmap keeps the mutex while auto-resuming.  For avoiding that,
      there is some tricky check in the HDA regmap handler to return -EAGAIN
      error to back-off when the codec is powered down.  Then the caller of
      regmap r/w will retry after properly turning on the codec power.
      
      This works in most cases, but there seems a slight race between the
      codec power check and the actual on-demand auto-resume trigger.  This
      resulted in the lockdep splat, eventually leading to a real deadlock.
      
      This patch tries to address the race window by getting the runtime PM
      refcount at the check time using pm_runtime_get_if_in_use().  With
      this call, we can keep the power on only when the codec has been
      already turned on, and back off if not.
      
      For keeping the code consistency, the code touching the runtime PM is
      stored in hdac_device.c although it's used only locally in
      hdac_regmap.c.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fc4f000b
  6. 07 Mar, 2016 8 commits
  7. 05 Mar, 2016 6 commits
  8. 04 Mar, 2016 8 commits
  9. 03 Mar, 2016 1 commit
  10. 02 Mar, 2016 1 commit
  11. 01 Mar, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: seq: oss: Don't drain at closing a client · 197b958c
      Takashi Iwai authored
      The OSS sequencer client tries to drain the pending events at
      releasing.  Unfortunately, as spotted by syzkaller fuzzer, this may
      lead to an unkillable process state when the event has been queued at
      the far future.  Since the process being released can't be signaled
      any longer, it remains and waits for the echo-back event in that far
      future.
      
      Back to history, the draining feature was implemented at the time we
      misinterpreted POSIX definition for blocking file operation.
      Actually, such a behavior is superfluous at release, and we should
      just release the device as is instead of keeping it up forever.
      
      This patch just removes the draining call that may block the release
      for too long time unexpectedly.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      197b958c