1. 12 6月, 2014 2 次提交
  2. 10 6月, 2014 3 次提交
  3. 06 6月, 2014 1 次提交
    • L
      ASoC: sigmadsp: Split regmap and I2C support into separate modules · 6b10998d
      Lars-Peter Clausen 提交于
      When the SigmaDSP module is built-in, but the I2C core is build as a module
      we'll get a undefined reference:
      
      	sound/built-in.o: In function `sigma_action_write_i2c':
      		:(.text+0x5d8d4): undefined reference to `i2c_master_send'
      
      This can happen if a audio driver that is using the regmap SigmaDSP interface is
      built into the kernel, but core I2C support is build as a module. To fix this
      split the SigmaDSP module into three modules, one module providing the core
      infrastructure and two small modules implementing the regmap and I2C interfaces.
      This allows e.g. the core infrastructure and regmap support to be built into the
      kernel while I2C support can still be build as a module.
      
      Fixes: dab464b6 ("ASoC: Add ADAU1361/ADAU1761 audio CODEC support")
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      6b10998d
  4. 05 6月, 2014 1 次提交
    • A
      ASoC: MMP audio needs sram support · 5ab0862e
      Arnd Bergmann 提交于
      From e7a94bb7fb871c73cc85712d89c1f48d0271c1be Mon Sep 17 00:00:00 2001
      From: Arnd Bergmann <arnd@arndb.de>
      Date: Thu, 5 Jun 2014 12:31:28 +0200
      Subject: [PATCH] ASoC: MMP audio needs sram support
      
      Building the pxa/mmp audio driver without support for the mmp
      sram driver enabled results in this link error:
      
      sound/built-in.o: In function `mmp_pcm_free_dma_buffers':
      :(.text+0x3e734): undefined reference to `sram_get_gpool'
      sound/built-in.o: In function `mmp_pcm_new':
      :(.text+0x3e7c0): undefined reference to `sram_get_gpool'
      
      The sram driver is cannot be manually enabled and needs to
      be turned on by selecting MMP_SRAM from each module that
      needs it, which is what this patch does.
      
      Ideally, MMP should move over to the generic SRAM support, but
      for the moment, we can avoid the build error.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Qiao Zhou <zhouqiao@marvell.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      5ab0862e
  5. 04 6月, 2014 1 次提交
    • A
      ASoC: pxa: add I2C dependencies as needed · 38784764
      Arnd Bergmann 提交于
      We have in the past added 'depends on I2C' for some of the PXA boards
      after hitting randconfig build bugs. I have seens a couple of new
      bugs in this area during the linux-next cycle for 3.16, after it
      became possible to build some more PXA machines with I2C disabled.
      
      To shut this up for good, this adds the dependency to every board
      that uses I2C as the interface to the codec. I have gone through
      all board files and verified that they all either use AC97 or
      I2C, and this annotates the latter. Some of these already enable
      I2C from mach-pxa/Kconfig, but since that can change it's better
      to be explicit here.
      
      The link error that can result otherwise happens when CONFIG_I2C
      is set to 'm' and the codec driver is built-in as a result of being
      selected by the platform specific glue.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      38784764
  6. 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
  7. 02 6月, 2014 7 次提交
  8. 01 6月, 2014 18 次提交
  9. 29 5月, 2014 1 次提交
  10. 28 5月, 2014 4 次提交