Skip to content

L
linux
Switch branch/tag
  1. 14 Mar, 2016 2 commits
  3. 11 Mar, 2016 1 commit
  5. 10 Mar, 2016 5 commits
  7. 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
  9. 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
  11. 07 Mar, 2016 8 commits
  13. 05 Mar, 2016 6 commits
  15. 04 Mar, 2016 8 commits
  17. 03 Mar, 2016 1 commit
  19. 02 Mar, 2016 1 commit
  21. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7