Skip to content
  • 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