of_get_named_gpio() was changed to return -EPROBE_DEFER in case of
gpios not probed yet. This patch adjusts tegra_wm8903 to this.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If mic detect is left enabled and the WM8903 detects a status change,
the WM8903 driver will make a callback against the free()d jack, which
will cause a crash.

This problem can be triggered by fully initializing an audio card, then
removing and re-inserting the machine driver module.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

rtd->codec_dai->codec can be used instead.

This is a slight step along the way to not needing the rtd->codec field
any more.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Define the DAI format statically in the dai_link, rather than executing
code to set it each time the hw params are set.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Prior to this patch, the CPU side of a DAI link was specified using a
single name. Often, this was the result of calling dev_name() on the
device providing the DAI, but in the case of a CPU DAI driver that
provided multiple DAIs, it needed to mix together both the device name
and some device-relative name, in order to form a single globally unique
name.

However, the CODEC side of the DAI link was specified using separate
fields for device (name or OF node) and device-relative DAI name.

This patch allows the CPU side of a DAI link to be specified in the same
way as the CODEC side, separating concepts of device and device-relative
DAI name.

I believe this will be important in multi-codec and/or dynamic PCM
scenarios, where a single CPU driver provides multiple DAIs, while also
booting using device tree, with accompanying desire not to hard-code the
CPU side device's name into the original .cpu_dai_name field.

Ideally, both the CPU DAI and CODEC DAI loops in soc_bind_dai_link()
would now be identical. However, two things prevent that at present:

1) The need to save rtd->codec for the CODEC side, which means we have
to search for the CODEC explicitly, and not just the CODEC side DAI.

2) Since we know the CODEC side DAI is part of a codec, and not just
a standalone DAI, it's slightly more efficient to convert .codec_name/
.codec_of_node into a codec first, and then compare each DAI's .codec
field, since this avoids strcmp() on each DAI's CODEC's name within
the loop.

However, the two loops are essentially semantically equivalent.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In kernel 3.6, Seaboard will only be supported when booting using device
tree; the board files are being removed. Hence, remove the non-DT support
for Seaboard and derivatives Kaen and Aebl from the audio driver.

Harmony is the only remaining board supported by this driver when not
using DT. This support is currently scheduled for removal in 3.7.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

By the time any widget callbacks could be called, if the GPIO ID they
will manipulate is valid, it must have already been requested, or the
card would have failed to probe or initialize. So, testing for GPIO
validity is equivalent to testing whether the GPIO was successfully
requested at this point in the code. Making this change will allow later
patches to remove the gpio_requested variable.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The headphone jack GPIOs are added/initialized in the DAI link's init()
method, and hence in theory may not always have been added before remove()
is called in some unusual cases. In order to prevent calling
snd_soc_jack_free_gpios() if snd_soc_jack_add_gpios() had not been, the
code kept track of the initialization state to avoid the free call when
necessary.

However, it appears that snd_soc_jack_free_gpios() is robust in the face
of being called without snd_soc_jack_add_gpios() first succeeding, so
there is little point manually tracking this information. Hence, remove
the tracking code. Almost all other machine drivers already operate this
way.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

By using this function, the driver no longer needs to explicitly free
the GPIOs. Hence, we can also remove the flags we use to track whether
we allocated these GPIOs.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Now that deferred probe exists, we can parse device tree and request
GPIOs from probe(), rather than deferring this to the DAI link's init().
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Rename Tegra20-specific Kconfig variables, module filenames, all internal
symbol names, clocks, and platform devices, to reflect the fact the DAS
and I2S drivers are for a specific HW version.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

These include aren't needed, and some of the files are about to be
renamed.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Previously, the ASoC 'platform' (PCM/DMA) object was instantiated via a
platform_device. This didn't represent the hardware well, since there
was no separate hardware associated with this platform_device; it was a
virtual device with sole purpose to call snd_soc_register_platform().
This mechanism required all board files to register this device, and all
ASoC machine drivers to create and register this device when booting
using device tree.

This change removes the platform_device completely. Each Tegra DAI now
registers the ASoC 'platform' itself. Machine drivers are adjusted for
the new 'platform' name.
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Missed .owner of struct snd_soc_card will prevent the module from being
removed from underneath its users.
Reported-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This driver is parameterized in two ways:

a) Platform data, which supplies the set of GPIOs used by the driver.
   These GPIOs can now be parsed out of device tree.

b) Machine-specific DAPM route arrays embedded into the ASoC machine
   driver itself. Historically, the driver picks the appropriate array
   to use using machine_is_*(). The driver now requires this array to
   be parsed from device tree when instantiated through device tree,
   using the core ASoC support for this parsing.

Based on work by John Bonesio, but significantly reworked since then.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Move DAS routing setup into the DAS driver itself. This removes the need
to duplicate this in each machine driver, of which we'll soon have three.

An added advantage is that the machine drivers no longer call the Tegra20-
specific DAS functions by name, so the machine driver no longer needs to
be split up into Tegra20 and Tegra30 versions.

If individual machine drivers need a different routing setup to this
default, they can still call the DAS functions to set that up.

Long-term, DAS will be a codec driver, and user-space will be able to
control its routing, possibly within constraints that the machine driver
sets up. Configuring the DAS routing from the DAS driver is a very slight
move in that direction.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Also rename it to MICBIAS to reflect the pin name and help any out of tree
users notice the change.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NStephen Warren <swarren@nvidia.com>

Set card.fully_routed to request the ASoC core calculated unused codec
pins, and call snd_soc_dapm_nc_pin() for them. Remove the open-coded
calls.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

module_platform_driver saves some boiler-plate code.

The devm_ APIs remove the need to manually clean up allocations,
thus removing some code.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This removes potentially machine-specific routing knowledge from the
I2S driverinto the machine drivers, which is better equipped to know
what the appropriate routing configuration is.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The core will sync DAPM as part of the card initialization, there is no
need for machine drivers to do so during their setup.

OMAP drivers are omitted as I know Peter already has patches for them.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Board file support for Ventana is not yet mainlined, and probably won't
ever be given the move to Device-Tree. Consequently, the Ventana entry
is being removed from arch/arm/tools/mach-types in the next merge window,
since it was registered over a year ago.

This will also remove function machine_is_ventana(), which is used by
the ASoC Tegra WM8903 machine driver. This will cause compilation
failures. Drop Ventana support to resolve this.

Hopefully, in the not-too-distant future, tegra_wm8903.c will be able to
configure itself from Device-Tree, and hence we'll be able to re-instate
Ventana support just by creating a .dts file for the board.

Also note that Aebl support is in a similar boat. However, that board
isn't scheduled for deprecation for at least another 5 months, and
perhaps we will have completely removed non-Device-Tree support from
tegra_wm8903.c by then and/or adjusted mach-types policy.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Two issues were preventing module snd-soc-tegra-wm8903.ko from being
removed and re-inserted:

a) The speaker-enable GPIO is hosted by the WM8903 chip. This GPIO must
   be freed before snd_soc_unregister_card() is called, because that
   triggers wm8903.c:wm8903_remove(), which calls gpiochip_remove(), which
   then fails if any of the GPIOs are in use. To solve this, free all GPIOs
   first, so the code doesn't care where they come from.

b) We need to call snd_soc_jack_free_gpios() to match the call to
   snd_soc_jack_add_gpios() during initialization. Without this, the
   call to snd_soc_jack_add_gpios() fails during any subsequent modprobe
   and initialization, since the GPIO and IRQ are already registered. In
   turn, this causes the headphone state not to be monitored, so the
   headphone is assumed not to be plugged in, and the audio path to it is
   never enabled.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Cc: stable@kernel.org
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We want the default state of the HP_MUTE signal to be asserted, so that
the headphones are muted before the first audio playback. Without this,
the headphones are left unmuted until shortly after the first audio
playback completes.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Replace calls to a variety of registration functions by updating
struct snd_soc_card snd_soc_tegra_wm8903 to directly point at the
various control/widget/map tables instead. The ASoC core now
performs any required registration based on these data fields.

(Applying Mark's TrimSlice review comments to the existing driver)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Card widgets are created in the card's DAPM context, not any codec's DAPM
context. Hence, w->codec==NULL. Instead, find the card from the widget
through the DAPM context of the widget, not the codec of the widget.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Only the clock programming code needs to know whether the clocks changed,
and that is encapsulated within tegra_asoc_utils_set_rate(). The machine
driver's call to snd_soc_dai_set_sysclk(codec_dai, ...) is safe
irrespective of whether the clocks changed.

(Applying Mark's TrimSlice review comments to the existing driver)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

When the driver is not initialized/registered, nothing should be touching
these fields anyway, so there's no point clearing them out.

(Applying Mark's TrimSlice review comments to the existing driver)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This machine driver is a platform driver, and hence will only be
instantiated on the correct machines. Hence, there is no need to
check the current machine during probe.

(Applying Mark's TrimSlice review comments to the existing driver)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

* Ventana is identical to Harmony.
* Seaboard, Kaen, and Aebl are all pretty similar, mainly with slightly
  different sets of GPIOs, and slightly different WM8903 pin connectivity.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Storing the struct in an array makes the assignments to the GPIO member a
little non-obvious, and is pointless when there's only a single GPIO.

(I thought I fixed this during the review cycle when first submitting this
driver, but I guess I overlooked that)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Soon, this machine driver will be updated to handle a number of Tegra boards
using the WM8903 codec. Rename the file in advance to reflect this.

Fix the content of tegra_wm8903.c to match the rename; replace references
to Harmony board with something more generic.

* s/struct tegra_harmony/struct tegra_wm8903/
* s/harmony/machine/ # variable name
* Similar rename for some functions
* Similar comment fix
* Similar MODULE_DESCRIPTION fix
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Soon, this machine driver will be updated to handle a number of Tegra boards
using the WM8903 codec. Rename the platform device in advance to reflect this.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The audio driver will soon support more than just the Tegra Harmony board.
Rename the platform data header file and data type to reflect this.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

ASoC machine drivers that are their own platform_driver (as opposed to
those using the soc-audio platform_driver) need to explicitly set up
power-management operation callbacks.

To avoid cut/paste, snd_soc_pm_ops also needs to be exported.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

With the appropriate MODULE_ALIAS in place, the audio modules will be
automatically loaded; there is no longer a need for manual modprobes.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Harmony has both an external mic (a regular mic jack) and an internal mic
(a 0.1" two-pin header on the board).

The external mic is connected to the WM8903's IN1L pin, and is supported
by the current driver.

The internal mic is connected to the WM8903's IN1R pin, and is not supported
by the current driver.

It appears that no Harmony systems were shipped with any internal mic
connected; users were expected to provide their own. This makes the
internal mic connection less interesting.

The WM8903's Mic Bias signal is used for both of these mics. For each mic,
a GPIO drives a transistor which gates whether the mic bias signal is
actively connected to that mic, or isolated from it.

The dual use of the mic bias for both mics makes a general-purpose complete
implementation of mic detection using the mic bias complex. So, for
simplicity, the internal mic is currently ignored by the driver.

This patch configures the relevant GPIOs to enable the mic bias connection
to the external mic, and disable the mic bias connection to the internal
mic. Note that in practice, this is the default state if these GPIOs aren't
configured.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

* Add jack definition for mic jack
* Request wm8903 to enable mic detection
* Force mic bias on, since it's required for mic detection
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

It causes noisy -codecs to appear in things like .codec_name.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>