1. 15 7月, 2014 4 次提交
    • A
      ASoC: samsung: remove unused DMA data · dd2380e3
      Arnd Bergmann 提交于
      The s3c_dma_client structures and the 'ch' and 'ops' members in
      s3c_dma_params were only used by the legacy DMA driver and serve
      no function any more. This removes any reference to them.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      dd2380e3
    • A
      ASoC: samsung: s3c24xx dmaengine follow-up · 8f501c7b
      Arnd Bergmann 提交于
      Commit ae602456 ("ASoC: samsung: drop support for legacy
      S3C24XX DMA API") removed the old code for the samsung specific
      DMA interfaces, now that everybody can use dmaengine.
      
      This picks up the few remaining pieces left over by that patch:
      
      The most important one is the removal of the dma_data->ops->started()
      calls in ac97. My understanding is that these are only required
      for drivers that do not support cyclic transfers, which the new dma
      engine driver now does, so we can simply remove them. This would also
      fix at least one bug in the ac97 driver on newer machines, which
      currently gives us a NULL pointer dereference from trying to call
      dma_data->ops->started().
      
      Further, we must no longer 'select' S3C2410_DMA, which conflicts
      with the dmaengine driver. The SND_S3C_DMA symbol is now
      useless, because it is always selected, so we can remove it
      and build the dmaengine support unconditionally.
      
      Finally, we should not 'select' S3C24XX_DMAC or S3C64XX_PL080,
      which may have additional dependencies. This replaces it with
      'depends on', to be more conservative.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      8f501c7b
    • K
      ASoC: samsung: no more support for S5P6440 and S5P6450 SoCs · 3a549fbf
      Kukjin Kim 提交于
      This patch removes s5p64x0 related WM8580 because of removing support
      for s5p64x0 SoCs.
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      [pebolle@tiscali.nl: reported missing dependency for smdk6450]
      Reported-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      3a549fbf
    • A
      ASoC: samsung: add explicit i2c/spi dependencies · d21e1b16
      Arnd Bergmann 提交于
      I got another build error from SND_SOC_SMARTQ selecting
      SND_SOC_WM8750 without ensuring that I2C is enabled,
      in this example, i2c is a loadable module:
      
      sound/built-in.o: In function `wm8750_i2c_probe':
      :(.text+0x3e6c0): undefined reference to `devm_regmap_init_i2c'
      sound/built-in.o: In function `wm8750_exit':
      :(.exit.text+0x3f4): undefined reference to `i2c_del_driver'
      sound/built-in.o: In function `wm8750_modinit':
      :(.init.text+0x13d0): undefined reference to `i2c_register_driver'
      
      This changes the samsund ASoC Kconfig to have explicit
      I2C dependencies for each driver that uses an i2c bus and
      SPI dependencies for the ones using those.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      d21e1b16
  2. 09 7月, 2014 1 次提交
  3. 05 7月, 2014 1 次提交
  4. 01 7月, 2014 1 次提交
  5. 27 6月, 2014 1 次提交
  6. 24 6月, 2014 4 次提交
  7. 22 6月, 2014 1 次提交
    • A
      ASoC: samsung: Add I2C dependency for snow · 5264d0e6
      Arnd Bergmann 提交于
      Both codecs used by snow, max98090 and max98095 require the use
      of I2C, so we can only select this driver if I2C is there, otherwise
      we get a build error like:
      
      codecs/max98090.c:2494:1: warning: data definition has no type or storage class [enabled by default]
       module_i2c_driver(max98090_i2c_driver);
       ^
      codecs/max98095.c:2443:1: warning: data definition has no type or storage class [enabled by default]
       module_i2c_driver(max98095_i2c_driver);
       ^
      
      This adds one more I2C dependency to the hundreds we already
      have.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NTushar Behera <tushar.behera@linaro.org>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      5264d0e6
  8. 03 6月, 2014 2 次提交
    • T
      ASoC: Fix wrong argument for card remove callbacks · 16088cb6
      Takashi Iwai 提交于
      The commit [e1d4d3c8: ASoC: free jack GPIOs before the sound card is
      freed] introduced snd_soc_card remove callbacks to a few drivers, but
      they are implemented with a wrong argument type.  The callback should
      receive snd_soc_card pointer instead of snd_soc_pcm_runtime.
      
      Fixes: e1d4d3c8 ('ASoC: free jack GPIOs before the sound card is freed')
      Acked-by: NMark Brown <broonie@linaro.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      16088cb6
    • S
      ASoC: free jack GPIOs before the sound card is freed · e1d4d3c8
      Stephen Warren 提交于
      This is the same change as commit fb6b8e71 "ASoC: tegra: free jack
      GPIOs before the sound card is freed", but applied to all other ASoC
      machine drivers where code inspection indicates the same problem exists.
      
      That commit's description is:
      ==========
      snd_soc_jack_add_gpios() schedules a work queue item to poll the GPIO to
      generate an initial jack status report. If sound card initialization
      fails, that work item needs to be cancelled, so it doesn't run after the
      card has been freed. Specifically, freeing the card calls
      snd_jack_dev_free() which calls snd_jack_dev_disconnect() which sets
      jack->input_dev = NULL, and input_dev is used by snd_jack_report(), which
      is called from the work queue item.
      
      snd_soc_jack_free_gpios() cancels the work item. The Tegra ASoC machine
      drivers do call this function in the platform driver remove() callback.
      However, this happens after the sound card is freed, at least when the
      card is freed due to errors late during snd_soc_instantiate_card(). This
      leaves a window where the work item can execute after the card is freed.
      In next-20140522, sound card initialization does fail for unrelated
      reasons, and hits the problem described above.
      
      To solve this, fix the Tegra ASoC machine drivers to clean up the Jack
      GPIOs during the snd_soc_card's .remove() callback, which is executed
      before the overall card object is freed. also, guard the cleanup call
      based on whether we actually setup up the GPIOs in the first place.
      Ideally, we'd do the cleanup in a struct snd_soc_dai_link .fini/remove
      function to match where the GPIOs get set up. However, there is no such
      callback.
      ==========
      
      Note that I have not even compile-tested this in most cases, since most
      of the drivers rely on specific mach-* support I don't have enabled, and
      don't support COMPILE_TEST. Testing by the relevant board maintainers
      would be useful.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      e1d4d3c8
  9. 02 6月, 2014 7 次提交
  10. 01 6月, 2014 18 次提交