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>

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>

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>

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>

Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

As we are moving the mmp platform towards multiplatform support,
we have to stop including platform header files.

This changes the pxa-ssp sound driver file to no longer depend
on mach/hardware.h and mach/dma.h. The code using the definitions
from those headers is actually gone already, the only thing
that was still being used was the pxa_dma_desc typedef, which
we can easily work around by using the normal 'struct pxa_dma_desc'
name.

The pxa2xx-dma driver still uses this header, so we include it
explicitly there, which is ok because that is only used on pxa,
not on mmp.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NXia Kaixu <kaixu.xia@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

ALSA SoC core marks widgets as connected by default when they are
initialized in snd_soc_dapm_new_control() so there is no need to call
snd_soc_dapm_enable_pin() from machine driver init functions.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

ALSA SoC core takes care of calling snd_soc_dapm_sync() at the end
snd_soc_instantiate_card() so there is no need to call it from machine
driver init functions.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The missing dependency can lead to build errors, so
make it explicit in Kconfig.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NXia Kaixu <kaixu.xia@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the controls and DAPM widgets and routes. This
on one hand makes the code a bit shorter and cleaner and on the other hand the
board level DAPM elements get registered in the card's DAPM context rather than
in the CODEC's DAPM context.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the controls and DAPM widgets and routes. This
on one hand makes the code a bit shorter and cleaner and on the other hand the
board level DAPM elements get registered in the card's DAPM context rather than
in the CODEC's DAPM context.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.

Also drop the two snd_soc_dapm_enable_pin() since pins are enabled by default
and there is no matching snd_soc_dapm_disable_pin() in the driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.

Also remove the snd_soc_dapm_enable_pin() calls, since pins are enabled by
default and there are no matching snd_soc_dapm_disable_pin() calls.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

When calling {corgi,poodle,spitz}_ext_control() from the startup callback we
pass the CODEC's DAPM context instead of the card's DAPM context. This is not a
problem per se since all the DAPM functions in ext_control() fallback to widgets
from other DAPM contexts, but passing the card's context is more consistent.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The locking here was added in commit 71a29560 ("ASoC: Lock the CODEC in PXA
external jack controls") to protect the DAPM changes that are made inside of
${board}_ext_control() against concurrent updates. The ASoC core was updated in
commit a73fb2df ("ASoC: dapm: Use DAPM mutex for DAPM ops instead of codec
mutex") to use a card wide lock rather the CODEC mutex to protect DAPM
operations. We now have proper locking inside ${board}_ext_control() itself, so
taking the CODEC lock can be removed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The ASoC core assumes that the PCM component of the ASoC card transparently
moves data around and does not impose any restrictions on the memory layout or
the transfer speed. It ignores all fields from the snd_pcm_hardware struct for
the PCM driver that are related to this. Setting these fields in the PCM driver
might suggest otherwise though, so rather not set them.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

use snd_dmaengine_pcm_prepare_slave_config to set slave config,
and remove the max_burst_size = 4 hard code.

select SND_SOC_GENERIC_DMAENGINE_PCM for mmp-pcm.
Signed-off-by: NQiao Zhou <zhouqiao@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: NNicolin Chen <b42378@freescale.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use WARN_ON() and handle the error cases accordingly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

This code sequence is unsafe in modules:

static u64 mask = DMA_BIT_MASK(something);
...
	if (!dev->dma_mask)
		dev->dma_mask = &mask;

as if a module is reloaded, the mask will be pointing at the original
module's mask address, and this can lead to oopses.  Moreover, they
all follow this with:

	if (!dev->coherent_dma_mask)
		dev->coherent_dma_mask = mask;

where 'mask' is the same value as the statically defined mask, and this
bypasses the architecture's check on whether the DMA mask is possible.

Fix these issues by using the new dma_coerce_coherent_and_mask()
function.
Acked-by: NMark Brown <broonie@linaro.org>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

After convertion to snd_soc_register_card, platform driver should
reference snd_soc_pm_ops callbacks to properly suspend/resume sound
hardware. This was missed during conversion of PXA sound devices.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

After recent changes to codec/DAI initialization order changes, codec
driver (wm9712 in my case) tries to access codec prior to
pxa2xx_ac97_hw_probe() being called (because DAIs are probed after all
codecs are probed). Move hw-related probe/remove/suspend/resume
functions to pxa2xx-ac97 driver level, instead of DAI level.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

devm_snd_soc_register_component makes code simpler.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

dmaengine.h header file was included twice.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

The bindings do not carry any resources, as the module only registers
the ASoC platform driver.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

With the new dmaengine implementation, the filter_data parameter has
to be set earlier, from pxa_ssp_startup().
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use snd_dmaengine_dai_dma_data for passing the dma parameters from
clients to the pxa pcm lib. This does no functional change, it's just an
intermedia step to migrate the pxa bits over to dmaengine.

The calculation of dcmd is a transition hack which will be removed again
in a later patch. It's just there to make the transition more readable.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pxa ssp DAI acts as a user of a pxa ssp port, and needs an
appropriate 'port' phandle in DT to reference the upstream.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

For the PXA DMA rework, we need the generic dmaengine implementation
that currently lives in sound/soc for standalone (non-ASoC) AC'97
support.

Move it to sound/core, and rename the Kconfig symbol.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NMark Brown <broonie@linaro.org>

Replace ARRAY_AND_SIZE(e) in function argument position to avoid hiding the
arity of the called function.

The semantic match that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e,f;
@@

f(...,
- ARRAY_AND_SIZE(e)
+ e,ARRAY_SIZE(e)
  ,...)
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NMark Brown <broonie@linaro.org>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add missing .owner of struct snd_soc_card. This prevents the
module from being removed from underneath its users.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMark Brown <broonie@linaro.org>