1. 22 Aug, 2017 1 commit
  2. 21 Aug, 2017 2 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add support for MOTU Audio Express · 3a93d082
      Takashi Sakamoto authored
      MOTU Audio Express is one of third generation in MOTU FireWire
      series, produced in 2011. This model consists of three chips:
       * TI TSB41AB2 (Physical layer for IEEE 1394 bus)
       * Microchip USB3300 (Hi-Speed USB Device with ULPI interface)
       * Xilinx Spartan-3A FPGA, XC3S400A (Link layer for IEEE 1394 bus, packet
         processing and data block processing layer)
      
      This commit adds support for this model. As I expected, it works with
      current implementaion of protocol version 3. On the other hand, the unit
      has a quirk to request subaction originated by any driver.
      
      11:45:51.287643 firewire_ohci 0000:03:00.0: AT spd 2 tl 1f, ffc1 -> ffc0, -reserved-, QW req, fffff0000b14 = 02000200
      11:45:51.289193 firewire_ohci 0000:03:00.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, W resp
      11:45:51.289381 fireire_core 0000:03:00.0: unsolicited response (source ffc0, tlabel 1f)
      11:45:51.313071 firewire_ohci 0000:03:00.0: AT spd 2 tl 20, ffc1 -> ffc0, ack_pending , QW req, fffff0000b14 = 02000200
      11:45:51.314539 firewire_ohci 0000:03:00.0: AR spd 2 tl 20, ffc0 -> ffc1, ack_complete, W resp
      
      In 1394 OHCI (rev.1.1), after OUTPUT_LAST* descriptors is processed,
      'xferStaus' field is filled with 'ContextControl[0:15]' (see clause 7.1.3).
      5 bits in LSB side of the field has ack code in acknowledge from the unit
      (see clause 7.2.2). A list of the code is shown in Table 3-2.
      
      As long as I investigated, in a case of the '-reserved-' acknowledge
      message from the unit, the field has 0x10. On the table, this value is
      'Reserved for definition by future 1394 standards'. As long as I know,
      any specifications of IEEE 1394 has no such extensions, thus the unit is
      out of specification. Besides, I note that the unit does not always
      acknowledge with the invalid code. I guess this is a bug of firmware. I
      confirmed the bug in firmware version 1.04 and this is the latest one.
      
      $ cd linux-firewire-utils
      $ python2 ./src/crpp < /sys/bus/firewire/devices/fw1/config_rom
                     ROM header and bus information block
                     -----------------------------------------------------------------
      400  0410a756  bus_info_length 4, crc_length 16, crc 42838
      404  31333934  bus_name "1394"
      408  20ff7000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
      40c  0001f200  company_id 0001f2     |
      410  000a8a7b  device_id 00000a8a7b  | EUI-64 0001f200000a8a7b
      
                     root directory
                     -----------------------------------------------------------------
      414  0004ef04  directory_length 4, crc 61188
      418  030001f2  vendor
      41c  0c0083c0  node capabilities per IEEE 1394
      420  d1000002  --> unit directory at 428
      424  8d000005  --> eui-64 leaf at 438
      
                     unit directory at 428
                     -----------------------------------------------------------------
      428  00031680  directory_length 3, crc 5760
      42c  120001f2  specifier id
      430  13000033  version
      434  17104800  model
      
                     eui-64 leaf at 438
                     -----------------------------------------------------------------
      438  00025ef3  leaf_length 2, crc 24307
      43c  0001f200  company_id 0001f2     |
      440  000a8a7b  device_id 00000a8a7b  | EUI-64 0001f200000a8a7b
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3a93d082
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add specification flag for position of flag for MIDI messages · 8b460c76
      Takashi Sakamoto authored
      In protocols of MOTU FireWire series, when transferring MIDI messages,
      transmitter set existence flag to one byte on first several quadlets. The
      position differs depending on protocols and models, however two cases are
      confirmed; in 5th byte and 8th byte from MSB side.
      
      This commit adds a series of specification flag to describe them. When
      the existence flag is in the 5th byte, SND_MOTU_SPEC_[R|T]X_MIDI_2ND_Q is
      used. Else, another set of the flag is used. Here, '_Q' means quadlet.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8b460c76
  3. 20 Aug, 2017 2 commits
  4. 19 Aug, 2017 1 commit
  5. 15 Aug, 2017 1 commit
  6. 19 Jun, 2017 1 commit
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: Fix stall of process context at packet error · 4a9bfafc
      Takashi Sakamoto authored
      At Linux v3.5, packet processing can be done in process context of ALSA
      PCM application as well as software IRQ context for OHCI 1394. Below is
      an example of the callgraph (some calls are omitted).
      
      ioctl(2) with e.g. HWSYNC
      (sound/core/pcm_native.c)
      ->snd_pcm_common_ioctl1()
        ->snd_pcm_hwsync()
          ->snd_pcm_stream_lock_irq
          (sound/core/pcm_lib.c)
          ->snd_pcm_update_hw_ptr()
            ->snd_pcm_udpate_hw_ptr0()
              ->struct snd_pcm_ops.pointer()
              (sound/firewire/*)
              = Each handler on drivers in ALSA firewire stack
                (sound/firewire/amdtp-stream.c)
                ->amdtp_stream_pcm_pointer()
                  (drivers/firewire/core-iso.c)
                  ->fw_iso_context_flush_completions()
                    ->struct fw_card_driver.flush_iso_completion()
                    (drivers/firewire/ohci.c)
                    = flush_iso_completions()
                      ->struct fw_iso_context.callback.sc
                      (sound/firewire/amdtp-stream.c)
                      = in_stream_callback() or out_stream_callback()
                        ->...
          ->snd_pcm_stream_unlock_irq
      
      When packet queueing error occurs or detecting invalid packets in
      'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
      is called on local CPU with disabled IRQ.
      
      (sound/firewire/amdtp-stream.c)
      in_stream_callback() or out_stream_callback()
      ->amdtp_stream_pcm_abort()
        ->snd_pcm_stop_xrun()
          ->snd_pcm_stream_lock_irqsave()
          ->snd_pcm_stop()
          ->snd_pcm_stream_unlock_irqrestore()
      
      The process is stalled on the CPU due to attempt to acquire recursive lock.
      
      [  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
      [  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
      [  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
      [  562.630866] Task dump for CPU 2:
      [  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
      [  562.630870] Call Trace:
      [  562.630876]  ? vt_console_print+0x79/0x3e0
      [  562.630880]  ? msg_print_text+0x9d/0x100
      [  562.630883]  ? up+0x32/0x50
      [  562.630885]  ? irq_work_queue+0x8d/0xa0
      [  562.630886]  ? console_unlock+0x2b6/0x4b0
      [  562.630888]  ? vprintk_emit+0x312/0x4a0
      [  562.630892]  ? dev_vprintk_emit+0xbf/0x230
      [  562.630895]  ? do_sys_poll+0x37a/0x550
      [  562.630897]  ? dev_printk_emit+0x4e/0x70
      [  562.630900]  ? __dev_printk+0x3c/0x80
      [  562.630903]  ? _raw_spin_lock+0x20/0x30
      [  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
      [  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
      [  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
      [  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
      [  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
      [  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
      [  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
      [  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
      [  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
      [  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
      [  562.630945]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630947]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
      [  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
      [  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
      [  562.630962]  ? futex_wake+0x90/0x170
      [  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
      [  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
      [  562.630972]  ? do_vfs_ioctl+0xa3/0x610
      [  562.630974]  ? vfs_read+0x11b/0x130
      [  562.630976]  ? SyS_ioctl+0x79/0x90
      [  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
      
      This commit fixes the above bug. This assumes two cases:
      1. Any error is detected in software IRQ context of OHCI 1394 context.
      In this case, PCM substream should be aborted in packet handler. On the
      other hand, it should not be done in any process context. TO distinguish
      these two context, use 'in_interrupt()' macro.
      2. Any error is detect in process context of ALSA PCM application.
      In this case, PCM substream should not be aborted in packet handler
      because PCM substream lock is acquired. The task to abort PCM substream
      should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
      returned at 'struct snd_pcm_ops.pointer()'.
      Suggested-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Fixes: e9148ddd("ALSA: firewire-lib: flush completed packets when reading PCM position")
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4a9bfafc
  7. 08 Jun, 2017 1 commit
  8. 07 Jun, 2017 2 commits
    • Takashi Sakamoto's avatar
      ALSA: fireface: constify ALSA specific operations · d2dc2a96
      Takashi Sakamoto authored
      ALSA fireface driver has ALSA specific operations for MIDI/PCM data.
      Structured data for the operations can be constified. Additionally,
      The structured data can be function local.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d2dc2a96
    • Takashi Sakamoto's avatar
      ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback · 875becf8
      Takashi Sakamoto authored
      In recent commit for ALSA PCM core, some arrangement is done for
      'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
      explicitly moved in intermediate buffer for PCM frames, except for
      some cases described later.
      
      For drivers in ALSA firewire stack, usage of this callback has a merit to
      reduce latency between time of PCM frame queueing and handling actual
      packets in recent isochronous cycle, because no need to wait for software
      IRQ context from isochronous context of OHCI 1394.
      
      If this works well in a case that mapped page frame is used for the
      intermediate buffer, user process should execute some commands for ioctl(2)
      to tell the number of handled PCM frames in the intermediate buffer just
      after handling them. Therefore, at present, with a combination of below
      conditions, this doesn't work as expected and user process should wait for
      the software IRQ context as usual:
       - when ALSA PCM core judges page frame mapping is available for status
         data (struct snd_pcm_mmap_status) and control data
         (struct snd_pcm_mmap_control).
       - user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
         and 'snd_pcm_mmap_commit()'.
       - user process uses PCM hw plugin in alsa-lib to operate I/O without
         'sync_ptr_ioctl' option.
      
      Unfortunately, major use case include these three conditions.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      875becf8
  9. 30 May, 2017 1 commit
    • Bhumika Goyal's avatar
      ALSA: declare snd_kcontrol_new structures as const · 905e46ac
      Bhumika Goyal authored
      Declare snd_kcontrol_new structures as const as they are only passed an
      argument to the function snd_ctl_new1. This argument is of type const,
      so snd_kcontrol_new structures having this property can be made const.
      Done using Coccinelle:
      
      @r disable optional_qualifier@
      identifier x;
      position p;
      @@
      static struct snd_kcontrol_new x@p={...};
      
      @ok@
      identifier r.x;
      position p;
      @@
      snd_ctl_new1(&x@p,...)
      
      @bad@
      position p != {r.p,ok.p};
      identifier r.x;
      @@
      x@p
      
      @depends on !bad disable optional_qualifier@
      identifier r.x;
      @@
      +const
      struct snd_kcontrol_new x;
      
      Cross compiled these files:
      sound/aoa/codecs/tas.c - powerpc
      sound/mips/{hal2.c/sgio2audio.c} - mips
      sound/ppc/{awacs.c/beep.c/tumbler.c} - powerpc
      sound/soc/sh/siu_dai.c - sh
      Could not find an architecture to compile sound/sh/aica.c.
      Signed-off-by: default avatarBhumika Goyal <bhumirks@gmail.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      905e46ac
  10. 22 May, 2017 1 commit
    • Takashi Sakamoto's avatar
      ALSA: firewire: remove support for 16 bit PCM samples in playback substream · a02cb8f8
      Takashi Sakamoto authored
      In IEC 61883-6, AM824 is described as format of data block. In this
      format, one data block consists of several data channels, which is aligned
      to 32 bit. One data channel has 8 bit label field and 24 bit data field.
      PCM frames are transferred in Multi Bit Linear Audio (MBLA) data channel.
      This channel can include 16/20/24 bit PCM sample.
      
      As long as I know, models which support IEC 61883-1/6 doesn't allow to
      switch bit length of PCM sample in MBLA data channel. They always
      transmit/receive PCM frames of 24 bit length. This can be seen for the
      other models which support protocols similar to IEC 61883-1/6.
      
      On the other hand, current drivers for these protocols supports 16 bit
      length PCM sample in playback substream. In this case, PCM sample is put
      into the MBLA data channel with 8 bit padding in LSB side. Although 16
      bit PCM sample is major because it's in CD format, this doesn't represent
      device capability as is.
      
      This commit removes support for 16 bit PCM samples in playback substream.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a02cb8f8
  11. 20 Apr, 2017 2 commits
  12. 14 Apr, 2017 9 commits
  13. 12 Apr, 2017 1 commit
  14. 11 Apr, 2017 3 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add tracepoints for messages for unique protocol · c6b0b9e6
      Takashi Sakamoto authored
      MOTU units transfer/receive messages in each data block of their
      isochronous packet payload. A part of content in the message is cleard for
      MIDI message transmission, while the rest is unknown yet. Additional
      features are required to assist users and developers to reveal the
      details.
      
      This commit adds tracepoints for the purpose. The tracepoints are designed
      for MOTU's protocol version 2 and 3 (Protocol version 1 is not upstreamed
      yet). In the tracepoints, events are probed to gather first two 24 bit
      data chunks of each data block. The chunks are formatted into elements
      of 64 bit array with padding in MSB.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c6b0b9e6
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashion · 17909c1b
      Takashi Sakamoto authored
      Unique protocol is used for MOTU FireWire series. In this protocol,
      data block format is not compliant to AM824 in IEC 61883-1/6. Each of
      the data block consists of 24 bit data chunks, except for a first
      quadlet. The quadlet is used for source packet header (SPH) described
      in IEC 61883-1.
      
      The sequence of SPH seems to represent presentation timestamp
      corresponding to included data. Developers have experienced that invalid
      sequence brings disorder of units in the series.
      
      Unfortunately, current implementation of ALSA IEC 61883-1/6 engine and
      firewire-motu driver brings periodical noises to the units at sampling
      transmission frequency based on 44.1 kHz. The engine generates the SPH with
      even interval and this mechanism seems not to be suitable to the units.
      Further work is required for this issue and infrastructure is preferable
      to assist the work.
      
      This commit adds tracepoints for the purpose. In the tracepoints, events
      are probed to gather the SPHs from each data blocks.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      17909c1b
    • Takashi Sakamoto's avatar
      ALSA: firewire_lib: add tracepoints for packets without CIP headers · b164d2fd
      Takashi Sakamoto authored
      Unique protocol is used for RME Fireface series. In this protocol,
      payload format for isochronous packet is not compliant to CIP in
      IEC 61883-1/6. The packet includes data blocks just with data channels,
      without headers and any metadata.
      
      In previous commits, ALSA IEC 61883-1/6 engine supports this protocol.
      However, tracepoints are not supported yet, unlike implementation for
      IEC 61883-1/6 protocol. This commit adds support of tracepoints for
      the protocol.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b164d2fd
  15. 05 Apr, 2017 12 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib/bebob/oxfw: improve response evaluation for AV/C commands · 7e1621de
      Takashi Sakamoto authored
      In ALSA firewire stack, some AV/C commands are supported, including
      vendor's extensions. Drivers includes response parser of each command,
      according to its requirements, while the parser is written with loose
      fashion in two points; error check and length check. This doesn't cause
      any issues such as kernel corruption, but should be improved.
      
      This commit modifies evaluations of return value on each parsers.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7e1621de
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: remove invalid bitshift for register value · 5b33504b
      Takashi Sakamoto authored
      In protocol version 3, drivers can read current sampling clock status from
      register 0x'ffff'f000'0b14. 8 bits of LSB of this register represents type
      of signal as source of clock.
      
      Current driver code includes invalid bitshift to handle the parameter. This
      commit fixes the bug.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 5992e300 ("ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5b33504b
    • Takashi Sakamoto's avatar
      ALSA: oxfw: fix regression to handle Stanton SCS.1m/1d · 3d016d57
      Takashi Sakamoto authored
      At a commit 6c29230e ("ALSA: oxfw: delayed registration of sound
      card"), ALSA oxfw driver fails to handle SCS.1m/1d, due to -EBUSY at a call
      of snd_card_register(). The cause is that the driver manages to register
      two rawmidi instances with the same device number 0. This is a regression
      introduced since kernel 4.7.
      
      This commit fixes the regression, by fixing up device property after
      discovering stream formats.
      
      Fixes: 6c29230e ("ALSA: oxfw: delayed registration of sound card")
      Cc: <stable@vger.kernel.org> # 4.7+
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3d016d57
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: remove transaction handler for unknown purpose · fdb2b2ee
      Takashi Sakamoto authored
      For digi00x series, asynchronous transaction is not used to transfer MIDI
      messages to/from control surface. One of transction handlers in my previous
      work loses its practical meaning.
      
      This commit removes the handler. I note that unit of console type
      transfers 0x00001000 to registered address of host space when switching
      to 'standalone' mode. Then the unit generates bus reset.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fdb2b2ee
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: allow user space applications to read/write MIDI messages for all ports · 0c3f15f3
      Takashi Sakamoto authored
      At a commit c5fcee03 ("ALSA: firewire-digi00x: add MIDI operations for
      MIDI control port"), I described that MIDI messages for control surface is
      transferred by a different way from the messages for physical ports.
      However, this is wrong. MIDI messages to/from all of MIDI ports are
      transferred by isochronous packets.
      
      This commit removes codes to transfer MIDI messages via asynchronous
      transaction, from MIDI handling layer.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0c3f15f3
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: handle all MIDI messages on streaming packets · 8820a4cf
      Takashi Sakamoto authored
      At a commit 9dc5d31c ("ALSA: firewire-digi00x: handle MIDI messages in
      isochronous packets"), a functionality to handle MIDI messages on
      isochronous packet was supported. But this includes some of my
      misunderstanding. This commit is to fix them.
      
      For digi00x series, first data channel of data blocks in rx/tx packet
      includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB,
      however it's against IEC 61883-6. Unique data format is applied:
       - Upper 4 bits of LSB represent port number.
        - 0x0: port 1.
        - 0x2: port 2.
        - 0xe: console port.
       - Lower 4 bits of LSB represent the number of included MIDI message bytes;
         0x0/0x1/0x2.
       - Two bytes of middle of this data channel have MIDI bytes.
      
      Especially, MIDI messages from/to console surface are also transferred by
      isochronous packets, as well as physical MIDI ports.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8820a4cf
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: add support for console models of Digi00x series · 13e005f9
      Takashi Sakamoto authored
      Digi00x series includes two types of unit; rack and console. As long as
      reading information on config rom of Digi 002 console, 'MODEL_ID' field
      has a different value from the one on Digi 002 rack.
      
      We've already got a test report from users with Digi 003 rack. We can
      assume that console type and rack type has different value in the field.
      
      This commit adds a device entry for console type. For following commits,
      this commit also adds a member to 'struct snd_digi00x' to identify console
      type.
      
      $ cd linux-firewire-utils/src
      $ python2 ./crpp < /sys/bus/firewire/devices/fw1/config_rom
                     ROM header and bus information block
                     -----------------------------------------------------------------
      400  0404f9d0  bus_info_length 4, crc_length 4, crc 63952
      404  31333934  bus_name "1394"
      408  60647002  irmc 0, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 7 (256)
      40c  00a07e00  company_id 00a07e     |
      410  00a30000  device_id 0000a30000  | EUI-64 00a07e0000a30000
      
                     root directory
                     -----------------------------------------------------------------
      414  00058a39  directory_length 5, crc 35385
      418  0c0043a0  node capabilities
      41c  04000001  hardware version
      420  0300a07e  vendor
      424  81000007  --> descriptor leaf at 440
      428  d1000001  --> unit directory at 42c
      
                     unit directory at 42c
                     -----------------------------------------------------------------
      42c  00046674  directory_length 4, crc 26228
      430  120000a3  specifier id
      434  13000001  version
      438  17000001  model
      43c  81000007  --> descriptor leaf at 458
      
                     descriptor leaf at 440
                     -----------------------------------------------------------------
      440  00055913  leaf_length 5, crc 22803
      444  000050f2  descriptor_type 00, specifier_ID 50f2
      448  80000000
      44c  44696769
      450  64657369
      454  676e0000
      
                     descriptor leaf at 458
                     -----------------------------------------------------------------
      458  0004a6fd  leaf_length 4, crc 42749
      45c  00000000  textual descriptor
      460  00000000  minimal ASCII
      464  44696769  "Digi"
      468  20303032  " 002"
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      13e005f9
    • Takashi Sakamoto's avatar
      ALSA: fireface: add support for Fireface 400 · 76fdb3a9
      Takashi Sakamoto authored
      Fireface 400 is a second model of RME Fireface series, released in 2006.
      This commit adds support for this model.
      
      This model supports 8 analog channels, 2 S/PDIF channels and 8 ADAT
      channels in both of tx/rx packet. The number of ADAT channels differs
      depending on each mode of sampling transmission frequency.
      
      $ python2 linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom
                     ROM header and bus information block
                     -----------------------------------------------------------------
      400  04107768  bus_info_length 4, crc_length 16, crc 30568 (should be 61311)
      404  31333934  bus_name "1394"
      408  20009002  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 9 (1024)
      40c  000a3501  company_id 000a35     |
      410  1bd0862a  device_id 011bd0862a  | EUI-64 000a35011bd0862a
      
                     root directory
                     -----------------------------------------------------------------
      414  000485ec  directory_length 4, crc 34284
      418  03000a35  vendor
      41c  0c0083c0  node capabilities per IEEE 1394
      420  8d000006  --> eui-64 leaf at 438
      424  d1000001  --> unit directory at 428
      
                     unit directory at 428
                     -----------------------------------------------------------------
      428  000314c4  directory_length 3, crc 5316
      42c  12000a35  specifier id
      430  13000002  version
      434  17101800  model
      
                     eui-64 leaf at 438
                     -----------------------------------------------------------------
      438  000261a8  leaf_length 2, crc 25000
      43c  000a3501  company_id 000a35     |
      440  1bd0862a  device_id 011bd0862a  | EUI-64 000a35011bd0862a
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      76fdb3a9
    • Takashi Sakamoto's avatar
      ALSA: fireface: add hwdep interface · f656edd5
      Takashi Sakamoto authored
      This commit adds hwdep interface so as the other drivers for audio and
      music units on IEEE 1394 have.
      
      This interface is designed for mixer/control applications. By using this
      interface, an application can get information about firewire node, can
      lock/unlock kernel streaming and can get notification at starting/stopping
      kernel streaming.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f656edd5
    • Takashi Sakamoto's avatar
      ALSA: fireface: add support for PCM functionality · 4b316436
      Takashi Sakamoto authored
      This commit adds PCM functionality to transmit/receive PCM frames on
      isochronous packet streaming. This commit enables userspace applications
      to start/stop packet streaming via ALSA PCM interface.
      
      Sampling rate requested by applications is used as sampling transmission
      frequency of IEC 61883-1/6packet streaming. As I described in followed
      commits, units in this series manages sampling clock frequency
      independently of sampling transmission frequency, and they supports
      resampling between their packet streaming/data block processing layer and
      sampling data processing layer. This commit take this driver to utilize
      these features for usability.
      
      When internal clock is selected as source signal of sampling clock, this
      driver allows user space applications to start PCM substreams at any rate
      which packet streaming engine supports as sampling transmission frequency.
      In this case, this driver expects units to perform resampling PCM frames
      for rx/tx packets when sampling clock frequency and sampling transmission
      frequency are mismatched. This is for daily use cases.
      
      When any external clock is selected as the source signal, this driver
      gets configured sampling rate from units, then restricts available
      sampling rate to the rate for PCM applications. This is for studio use
      cases.
      
      Models in this series supports 64.0/128.0 kHz of sampling rate, however
      these frequencies are not supported by IEC 61883-6 as sampling transmission
      frequency. Therefore, packet streaming engine of ALSA firewire stack can't
      handle them. When units are configured to use any external clock as source
      signal of sampling clock and one of these unsupported rate is configured
      as rate of the sampling clock, this driver returns EIO to user space
      applications.
      
      Anyway, this driver doesn't voluntarily configure parameters of sampling
      clock. It's better for users to work with appropriate user space
      implementations to configure the parameters in advance of usage.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4b316436
    • Takashi Sakamoto's avatar
      ALSA: fireface: add stream management functionality · 75d6d898
      Takashi Sakamoto authored
      This commit adds management functionality for packet streaming.
      
      As long as investigating Fireface 400, there're three modes depending
      on sampling transmission frequency. The number of data channels in each
      data block is different depending on the mode. The set of available
      data channels for each mode might be different for each protocol and
      model.
      
      The length of registers for the number of isochronous channel is just
      three bits, therefore 0-7ch are available.
      
      When bus reset occurs on IEEE 1394 bus, the device discontinues to
      transmit packets. This commit aborts PCM substreams at bus reset handler.
      
      As I described in followed commits, The device manages its sampling clock
      independently of sampling transmission frequency against IEC 61883-6.
      Thus, it's a lower cost to change the sampling transmission frequency,
      while data fetch between streaming layer and DSP require larger buffer
      for resampling. As a result, device latency might tend to be larger than
      ASICs for IEC 61883-1/6 such as DM1000/DM1100/DM1500 (BeBoB),
      DiceII/TCD2210/TCD2220/TCD3070 and OXFW970/971.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      75d6d898
    • Takashi Sakamoto's avatar
      ALSA: fireface: add unique data processing layer · 6fb7db90
      Takashi Sakamoto authored
      As long as investigating Fireface 400, format of payload of each
      isochronous packet is not IEC 61883-1/6, thus its format of data block
      is not AM824. The remarkable points of the format are:
       * The payload just consists of some data channels of quadlet size without
         CIP header.
       * Each data channels includes data aligned to little endian order.
       * One data channel consists of two parts; 8 bit ancillary field and 24 bit
         PCM frame.
      
      Due to lack of CIP headers, rx/tx packets include no CIP headers and
      different way to check packet discontinuity. For tx packet, the ancillary
      field is used for counter. However, the way of counting is different
      depending on positions of data channels. At 44.1 kHz, ancillary field in:
       * 1st/6th/9th/10th/14th/17th data channels: not used for this purpose.
       * 2nd/18th data channels: incremented every data block (0x00-0xff).
       * 3rd/4th/5th/11th/12th/13th data channels: incremented every 256 data
         blocks (0x00-0x07).
       * 7th/8th/15th/16th data channels: incremented per the number of data
         blocks in a packet. The increment can occur per packet (0x00-0xff).
      
      For tx packet, tag of each isochronous packet is used for this purpose.
      The value of tag cyclically changes between 0, 1, 2 and 3 in this order.
      The interval is different depending on sampling transmission frequency.
      At 44.1/48.0 kHz, it's 256 data blocks. At 88.2 kHz, it's 96 data blocks.
      
      The number of data blocks in tx packet is exactly the same as
      SYT_INTERVAL. There's no empty packet or no-data packet, thus the
      throughput is not 8,000 packets per sec. On the other hand, the one in
      rx packet is 8,000 packets per sec, thus the number of data blocks is
      different between each packet, depending on sampling transmission
      frequency:
       * 44.1 kHz: 5 or 6
       * 48.0 kHz: 5 or 6 or 7
       * 88.2 kHz: 10 or 11 or 12
      
      This commit adds data processing layer to satisfy the above specification
      in a policy of 'best effort'. Although PCM frames are handled for
      intermediate buffer to user space, the ancillary data is not handled at all
      to reduce CPU usage, thus counter is not checked. 0 is always used for tag
      of isochronous packet. Furthermore, the packet streaming layer is
      responsible for calculation of the number of data blocks for each packet,
      thus it's not exactly the same sequence from the above observation.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6fb7db90