1. 09 Mar, 2016 3 commits
    • 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
  2. 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
  3. 07 Mar, 2016 8 commits
  4. 05 Mar, 2016 6 commits
  5. 04 Mar, 2016 8 commits
  6. 03 Mar, 2016 1 commit
  7. 02 Mar, 2016 1 commit
  8. 01 Mar, 2016 10 commits