1. 30 5月, 2017 1 次提交
    • B
      ALSA: declare snd_kcontrol_new structures as const · 905e46ac
      Bhumika Goyal 提交于
      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: NBhumika Goyal <bhumirks@gmail.com>
      Acked-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      905e46ac
  2. 19 10月, 2015 1 次提交
    • T
      ALSA: bebob: use correct type for __be32 data · fef586d5
      Takashi Sakamoto 提交于
      In former commit, metering is supported for BeBoB based models
      customized by M-Audio. The data in transaction is aligned to
      big-endianness, while in the driver code u16 typed variable is assigned
      to the data. This causes sparse warnings.
      
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      
      This commit fixes this bug by using __be16 variable for the data.
      
      Fixes: 3149ac48('ALSA: bebob: Add support for M-Audio special Firewire series')
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      fef586d5
  3. 12 10月, 2015 1 次提交
  4. 15 6月, 2015 2 次提交
  5. 09 4月, 2015 1 次提交
  6. 21 10月, 2014 2 次提交
  7. 22 7月, 2014 4 次提交
  8. 27 5月, 2014 1 次提交
  9. 26 5月, 2014 3 次提交
    • T
      ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series · a2b2a779
      Takashi Sakamoto 提交于
      Just powering on, these devices below wait to download firmware.
       - Firewire Audiophile
       - Firewire 410
       - Firewire 1814
       - ProjectMix I/O
      
      But firmware version 5058 or later, flash memory in the device stores the
      firmware. So this driver can enable these devices by sending a certain cue to
      load the firmware.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a2b2a779
    • T
      ALSA: bebob: Add support for M-Audio special Firewire series · 3149ac48
      Takashi Sakamoto 提交于
      This commit allows this driver to support some models which M-Audio produces
      with DM1000 but its firmware is special. They are:
       - Firewire 1814
       - ProjectMix I/O
      
      They have heavily customized firmware. The usual operations can't be applied to
      them. For this reason, this commit adds a model specific member to 'struct
      snd_bebob' and some model specific functions. Some parameters are write-only so
      this commit also adds control interface for applications to set them.
      
      M-Audio special firmware quirks:
       - Just after powering on, they wait to download firmware. This state is
         changed when receiving cue. Then bus reset is generated and the device is
         recognized as a different model with the uploaded firmware.
       - They don't respond against BridgeCo AV/C extension commands. So drivers
         can't get their stream formations and so on.
       - They do not start to transmit packets only by establishing connection but
         also by receiving SIGNAL FORMAT command.
       - After booting up, they often fail to send response against driver's request
         due to mismatch of gap_count.
      
      This module don't support to upload firmware.
      
      Tested-by: Darren Anderson <darrena092@gmail.com> (ProjectMix I/O)
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3149ac48
    • T
      ALSA: bebob: Add support for M-Audio usual Firewire series · 9076c22d
      Takashi Sakamoto 提交于
      This commit allows this driver to support some models which M-Audio produces
      with DM1000/DM1000E with usual firmware. They are:
       - Firewire 410
       - Firewire AudioPhile
       - Firewire Solo
       - Ozonic
       - NRV10
       - FirewireLightBridge
      
      According to a person who worked in BridgeCo, some models are produced with
      'Pre-BeBoB'. This means that these products were released before BeBoB was
      officially produced, and later BeBoB specification was formed. So these models
      have some quirks.
      
      M-Audio usual firmware quirks:
       - Just after powering on, 'Firewire 410' waits to download firmware. This
         state is changed when receiving cue. Then bus reset is generated and the
         device is recognized as a different model with the uploaded firmware.
       - 'Firewire Audiophile' also waits to download firmware but its
         vendor id/model id is the same as the one after loading firmware.
       - The information of channel mapping for MIDI conformant data channel is
         invalid against BridgeCo specification.
      
      This commit adds some codes for these quirks but don't support to upload
      firmware.
      
      This commit also adds specific operations to get metering information. The
      metering information also includes status of clock synchronization if the model
      supports to switch source of clock.
      
      The specification of FirewireLightBridge is unknown. So in this time, normal
      operations are applied for this model.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9076c22d