ASoC: Reverts: Squash of all reverts for audio

This patch is squash of all reverts for older audio patches.

1. Revert "TEMP: ASoC: Samsung: i2s: Fix crash in i2s driver"

This reverts commit 5739f2d3fcbcd983fe23cb1c383790a93d7dccd0.

2. Revert "TEMP: ASoC: samsung: let device core setup the default pin configuration"

This reverts commit faf15f7d084e7213074083283175e2678b1d9fd4.

3. Revert "CHROMIUM: alsa/soc: adding support for hdmi audio to i2s card"

This reverts commit 891a6502572ab8c76ac4b480023f896767641b67.

4. Revert "CHROMIUM: ASoC: samsung i2s - Don't setup if already active."

This reverts commit 64070d3f87d7c737ca22621f58c59f6f84bde756.

5. Revert "CHROMIUM: Asoc: Samsung: Add I2S S/W RST in startup function"

This reverts commit d618f623db32421f37a7e6572b673f694081f528.

6. Revert "CHROMIUM: Asoc: Samsung: Add support for I2S runtime S2R"

This reverts commit e9c89b15e882cbb850f5bff892f644afefb7c85e.

7. Revert "CHROMIUM: ASoC: SAMSUNG: Add DT support for i2s"

This reverts commit 6eb17f88fde4d2ef20caa498320cf057ee7b8bf6.

8. Revert "CHROMIUM: ASoC: Samsung: Rename samsung i2s secondary device name"

This reverts commit 36724eaa4715280fecb8aedaeee9fe322d8129ca.

9. Revert "CHROMIUM: ARM: EXYNOS5: Add device tree support for audio"

This reverts commit c0d751b6c055a6c8c4d76a8412f1e6f4c77ac342.

10. Revert "CHROMIUM: ARM: dts: Add nodes for i2s controllers for Samsung EXYNOS5 platforms"

This reverts commit 3b24027a4a18dc365fba89b0bf4ae33b1b9981f5.

11. Revert "CHROMIUM: ASoC: SMDK: wm8994: Add .pm to struct smdk_audio_driver"

This reverts commit 26b2d5a37054b095b276b0995922008c9e6df2d3.

12. Revert "CHROMIUM: ASoC: SMDK: WM8994: Add device tree lookup support"

This reverts commit e0de330bdd5e6cec1a14d493386e4921df544cdc.

13. Revert "CHROMIUM: ARM: EXYNOS: Enable platform support for I2S controllers"

This reverts commit 630c40fa59ce6634368de6d27034d0e0a34c2182.

Change-Id: Ib6d5f4ef4b97cccd92e8fa915e2f693292b82329
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
UPSTREAM: ASoC: samsung: Rename samsung i2s secondary device name

All Samsung SoCs has max 3 i2s controllers. So the i2s secondary fifo
interface device id was named as samsung-i2s.4. Renaming this to
"samsung-i2s-sec" to support device tree in i2s driver.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit 7c62eebbf7d1cdaec68ab9d2d4017007f9312391)

Change-Id: I9edb057b71b7c4c889c5a923829cff0000885739
UPSTREAM: ASoC: Samsung: Add I2S S/W RST in startup function

I2S module need to be reset after S2R. Keeping the S/W rst
control part in resume didn't help in playing audio after resume.
So this patch adds S/W RST control part in startup function which
gets triggered for every new audio stream playback.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: R. Chandrasekar <rcsekar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit 2d77828d9904494d3c7424189ee38cc07950df5e)

Change-Id: I048bb3fbab20e2e18b79db81c7615a2afd4ca27d
UPSTREAM: ASoC: samsung: Add DT support for i2s

Add support for device based discovery.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit 40476f61897933d524b7069a6df65629a469d922)

Change-Id: I1edbaae7c954768202cb7acd9fce6fa603ab7752
UPSTREAM: ASoC: Samsung: I2S: Add support for runtime S2R

This patch adds runtime suspend to resume support for I2S.
I2S clk is disabled at suspend and enabled at resume.

Signed-off-by: R. Chandrasekar <rcsekar@samsung.com>
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit 5b1d3c3472f1941ab1a78575fe9ada718a7c0c25)

Change-Id: Ibb8ab5845cf52ce5ff975046d3bad6d8f489f760
CHROMIUM: ASoC: samsung i2s - Don't setup if already active.

If the dai is already running when setup is called, skip setup.  Setting
up again caused set_sysclk to set rclk_srcrate to other->rclk_srcrate,
other would often be set to the default of 44.1.  Playing a 48k stream
then adding a 48k capture stream would lead to both streams set to 44.1
(The value of other->rclk_srcrate).

Similarly in shutdown, if either playback or capture are still active,
return instead of turning off the clocks.

BUG=chrome-os-partner:13769, 13749
TEST=aplay -Dhw:0 <any 48k wav file>, then arecord -Dhw:0 -f dat
/tmp/asdf.wav.  Make sure audio continues from aplay and is captured by
arecord, before this change aplay would stop and arecord would capture
silence.
Gmail settings, make sure microphone progress bar moves when you talk.

Change-Id: I1dd02854e234d23ac25ad686c7603e4bc9265b4e
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32477
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: alsa/soc: adding support for hdmi audio to i2s card

This patch adds hdmi-audio plugin to i2s card. It also contains the changes
for DAPM changes and Error fixes from Sean and Vincent.

Change-Id: I25c7d9c23c91caccc6127301dc86be949fc92e63
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
UPSTREAM: of: Add generic device tree DMA helpers

This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.

Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
  Thinking about DMA controllers purely from the context of the hardware to
  begin with, we can describe a device in terms of a DMA controller as
  follows ...
  	1. Number of DMA controllers
	2. Number of channels (maybe physical or logical)
	3. Mapping of DMA requests signals to DMA controller
	4. Number of DMA interrupts
	5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
  the above information from the DT and provide to the appropriate driver.
  However, due to the vast number of DMA controllers and not all are using a
  common driver (such as DMA Engine) it has been seen that this is not a
  trivial task. In previous discussions on this topic the following concerns
  have been raised ...
	1. How does the binding support devices with multiple DMA controllers?
  	2. How to support both legacy DMA controllers not using DMA Engine as
	   well as those that support DMA Engine.
	3. When using with DMA Engine how do we support the various
	   implementations where the opaque filter function parameter differs
	   between implementations?
	4. How do we handle DMA channels that are identified with a string
	   versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
  an agreement what can be or should be supported.

Design of DMA helpers

1. Registering DMA controllers

   In the case of DMA controllers that are using DMA Engine, requesting a
   channel is performed by calling the following function.

	struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
			dma_filter_fn filter_fn,
			void *filter_param);

   The mask variable is used to match a type of the device controller in a list
   of controllers. The filter_fn and filter_param are used to identify the
   required dma channel and return a handle to the dma channel of type dma_chan.

   From the examples I have seen, the mask and filter_fn are constant
   for a given DMA controller and therefore, we can specify these as controller
   specific data when registering the DMA controller with the device-tree DMA
   helpers.

   The filter_param variable is of an unknown type and is typically specific
   to the DMA engine implementation for a given DMA controller. To allow some
   flexibility in the type and formating of this filter_param we employ an
   xlate to translate the device-tree binding information into the appropriate
   format. The xlate function used for a DMA controller can also be specified
   when registering the DMA controller with the device-tree DMA helpers.

   Based upon the above, a function for registering the DMA controller with the
   DMA helpers now looks like the below. The data variable is used to pass a
   pointer to DMA controller specific data used by the xlate function.

	int of_dma_controller_register(struct device_node *np,
		struct dma_chan *(*of_dma_xlate)
		(struct of_phandle_args *, struct of_dma *),
		void *data)

   For example, in the case where DMA engine is used, we define the following
   structure (that stores the DMA engine capability mask and filter function)
   and pass this to the data variable in the above function.

	struct of_dma_filter_info {
		dma_cap_mask_t  dma_cap;
		dma_filter_fn   filter_fn;
	};

2. Representing and requesting channel information

   Please see the dma binding documentation included in this patch for a
   description of how DMA controllers and client information should be
   represented with device-tree. For more information on how this binding
   came about please see [3]. In addition to this, feedback received from
   the Linux kernel summit showed a consensus (among those who attended) to
   use a name to identify DMA client information [4].

   A DMA channel can be requested by calling the following function, where name
   is a required parameter used for identifying a DMA channel. This function
   has been designed to return a structure of type dma_chan to work with the
   DMA engine driver. Note that if DMA engine is used then drivers should be
   using the DMA engine API dma_request_slave_channel() (implemented in part 2
   of this series, "dmaengine: add helper function to request a slave DMA
   channel") which will in turn call the below function if device-tree is
   present. The aim being to have a common DMA engine interface regardless of
   whether device tree is being used.

	struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
						      char *name)

3. Supporting legacy devices not using DMA Engine

   These devices present a problem, as there may not be a uniform way to easily
   support them with regard to device tree. Ideally, these should be migrated
   to DMA engine. However, if this is not possible, then they should still be
   able to use this binding, the only constaint imposed by this implementation
   is that when requesting a DMA channel via of_dma_request_slave_channel(), it
   will return a type of dma_chan.

This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
have validated that MMC is working on the PANDA board with this implementation.
My development branch for testing on OMAP can be found here [5].

v6: - minor corrections in DMA binding documentation
v5: - minor update to binding documentation
    - added loop to exhaustively search for a slave channel in the case where
      there could be alternative channels available
v4: - revert the removal of xlate function from v3
    - update the proposed binding format and APIs based upon discussions [3]
v3: - avoid passing an xlate function and instead pass DMA engine parameters
    - define number of dma channels and requests in dma-controller node
v2: - remove of_dma_to_resource API
    - make property #dma-cells required (no fallback anymore)
    - another check in of_dma_xlate_onenumbercell() function

[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
[4] http://pad.linaro.org/arm-mini-summit-2012
[5] https://github.com/jonhunter/linux/tree/dev-dt-dma

Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
(cherry picked from commit aa3da644c76d1c2083d085e453c18f7c51f19bc4)

Change-Id: Idde9c0b8bb32151424378378cc83e9567e4adfe7
UPSTREAM: of: dma- fix build break for !CONFIG_OF

Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
(cherry picked from commit 4c26bc601d20fa67eefcb27477feda130c10790e)

Change-Id: Icb5c439102537e8e32db7f4ca7641a5e8bd9d4c1
UPSTREAM: of: dma: fix protection of DMA controller data stored by DMA helpers

In the current implementation of the OF DMA helpers, read-copy-update (RCU)
linked lists are being used for storing and accessing the DMA controller data.
This part of implementation is based upon V2 of the DMA helpers by Nicolas [1].
During a recent review of RCU, it became apparent that the code is missing the
required rcu_read_lock()/unlock() calls as well as synchronisation calls before
freeing any memory protected by RCU.

Having looked into adding the appropriate RCU calls to protect the DMA data it
became apparent that with the current DMA helper implementation, using RCU is
not as attractive as it may have been before. The main reasons being that ...

1. We need to protect the DMA data around calls to the xlate function.
2. The of_dma_simple_xlate() function calls the DMA engine function
   dma_request_channel() which employs a mutex and so could sleep.
3. The RCU read-side critical sections must not sleep and so we cannot hold
   an RCU read lock around the xlate function.

Therefore, instead of using RCU, an alternative for this use-case is to employ
a simple spinlock inconjunction with a usage count variable to keep track of
how many current users of the DMA data structure there are. With this
implementation, the DMA data cannot be freed until all current users of the
DMA data are finished.

This patch is based upon the DMA helpers fix for potential deadlock [2].

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[2] http://marc.info/?l=linux-arm-kernel&m=134859982520984&w=2

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
(cherry picked from commit 9743a3b62dee8c9d8af1319f8d1c1ff39130267d)

Change-Id: I9c36a5c98e8f7cfc42c3d395db5842c197fdb7c5
UPSTREAM: dmaengine: fix !of_dma compilation warning

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
(cherry picked from commit 91f8aecc501e456c97a6f49f7ea3797e874d5d89)

Change-Id: Ib5b6ad1072f100b4919f3344181e93eba43a6d44
UPSTREAM: dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c

as requested by Rob

Suggested-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit 5fa422c922c2599dbfd960faf6dfca2411cc3f99)

Change-Id: If555126463b5c8903f086b373a16129d9a214e8d
UPSTREAM: dma: of-dma.c: fix memory leakage

The memory allocated to ofdma might be a leakage when error occurs.

Signed-off-by: Cong Ding <dinggnu@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit e68b1130dfbb834a4a028df01133591aeb59d241)

Change-Id: I094f30c9732a1280c6068d8a0cb7f61f0bdd41ef
UPSTREAM: dma: of-dma: protect list write operation by spin_lock

It's possible to have an inconsistency in the list due to unprotected operation
on it. The patch adds a proper locking on the list operation.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit 88b386c0a7c278581d2b8e2c2761d12f6475938d)

Change-Id: I078270f81498fa831c6700ffb89d352cdb029ed3
UPSTREAM: dmaengine: add helper function to request a slave DMA channel

Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.

With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.

Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
(cherry picked from commit 9a6cecc846169159bfce511f4c0034bb96eea1ca)

Change-Id: I4fafb84a611a7822da0c97bb16721879153140d7
UPSTREAM: DMA: PL330: Add new pl330 filter for DT case.

This patch adds a new pl330_dt_filter for DT case to filter the
required channel based on the new filter params and modifies the
old filter only for non-DT case as suggested by Arnd Bergmann.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit 34d19355b84adde9eebc1d6771231c15dff891e6)

Change-Id: I98cf21fbe1053334f208adaaba2e7b065a3efd84
UPSTREAM: DMA: PL330: Add xlate function

Add xlate to translate the device-tree binding information into
the appropriate format. The filter function requires the dma
controller device and dma channel number as filter_params.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit a80258f9b2ac81e72ff680d273df9544a1307a32)

Change-Id: I6a58c1e07d5a7916c31a0b1bb3019d573391a3d9
UPSTREAM: DMA: PL330: Register the DMA controller with the generic DMA helpers

This patch registers the pl330 dma controller driver with the generic
device tree dma helper functions.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit 421da89aadd1b24f4a3bc1d60c9de9825ec2debc)

Change-Id: I53dcb3b69683b6eb4c39e3a6bdf635a01b9c434e
UPSTREAM: ARM: SAMSUNG: Make dma request compatible to generic dma bindings.

This patch make the dma dev request operation compatible for both
DT and non-DT cases. It takes the all the arguments required for
dma_request_slave_channel and dma_request_channel. If the driver
is initiated via DT or non-DT the corresponding call will be made.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065)

Change-Id: I16d45e1e9d0f897fe6d1a2c4a4756ef173479175
UPSTREAM: ARM: SAMSUNG: Remove unnecessary code for dma

This patch removes the usage of DMACH_DT_PROP and dt_dmach_prop
from dma code as the new generic dma dt binding support has been
added.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
(cherry picked from commit ba7a9a784fbcfe1f0d9b3613c78f21a6fec94768)

Change-Id: I264393d4da5a4ffc7b390810f5acb094c0756345