ARM: tegra: rebuild tegra_defconfig on next-20140520

This makes it easier to create isolated defconfig patches

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Rebuild multi_v7_defconfig on next-20140520

Signed-off-by: Stephen Warren <swarren@nvidia.com>
LOCAL HACK: tegra_defconfig changes

Signed-off-by: Stephen Warren <swarren@nvidia.com>
WIP: ARM: tegra: venice2 WiFi

Signed-off-by: Stephen Warren <swarren@nvidia.com>
mfd: cros_ec: spi: calculate delay between transfers correctly

To avoid spamming the EC we calculate the time between the previous
transfer and the current transfer and force a delay if the time delta
is too small.

However, a small miscalculation causes the delay period to be
far too short. Most noticably this impacts commands with a long
turnaround time such as EC firmware reads and writes.

Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
mfd: cros_ec: spi: Add mutex to cros_ec_spi

The main transfer function for cros_ec_spi can be called by more than
one client at a time.  Make sure that those clients don't stomp on
each other by locking the bus for the duration of the transfer
function.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable

The cros_ec_spi transfer had two problems with its timeout code:

1. It looked at the timeout even in the case that it found valid data.
2. If the cros_ec_spi code got switched out for a while, it's possible
   it could get a timeout after a single loop.  Let's be paranoid and
   make sure we do one last transfer after the timeout expires.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms

We're adding i2c tunneling to the list of things that goes over
cros_ec.  i2c tunneling can be slooooooow, so increase our deadline to
100ms to account for that.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

This just updates include/linux/mfd/cros_ec_commands.h to match the
latest EC version (which is the One True Source for such things).  See
<https://chromium.googlesource.com/chromiumos/platform/ec>

[dianders: took today's ToT version from the Chromium OS EC; deleted
references to cros_ec_dev and cros_ec_lpc since those aren't upstream
yet]

Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
i2c: ChromeOS EC tunnel driver

On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main "Application Processor") and the EC (the Embedded
Controller).  These are:
* The battery (sbs-battery).
* The power management unit tps65090.

On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).

The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
  were caused by the EC, the AP, or some device on the bus).

On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
  longer on the bus used for AP/EC communication.  The battery was
  exposed to the AP through a limited i2c tunnel and tps65090 was
  exposed to the AP through a custom Linux driver.

On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.

The upstream "tegra124-venice2" uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.

This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: defconfig updates for cros_ec SPI/I2C bridge

These devices exist on the Tegra Venice2 board, behind the recently
added SPI->EC->I2C bridge.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: multi_v7_defconfig: add some devices for Tegra

These devices exist on the Tegra Venice2 board, behind the recently
added SPI->EC->I2C bridge.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ALSA: hda/hdmi - Add Nvidia Tegra124 HDMI support

Add the Tegra12x HDA codec id to patch_hdmi.

Signed-off-by: Sumit Bhattacharya <sumitb@nvidia.com>
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ALSA: hda - Add driver for Tegra SoC HDA

This adds a driver for the HDA block in Tegra SoCs.  The HDA bus is
used to communicate with the HDMI codec on Tegra124.

Most of the code is re-used from the Intel/PCI HDA driver.  It brings
over only two of the module params, power_save and probe_mask.

Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Add Tegra124 HDA support

Add a device node for the HDA controller found on Tegra124.

Signed-off-by: Dylan Reid <dgreid@chromium.org>
[swarren, fixed typo in clock/reset names]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: venice2 - Enable HDA

Turn on the HDA controller in Venice2, it is used for HDMI audio.

Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: enable HD-Audio controller in defconfig

The HD-audio controller provides HDMI audio support.

Signed-off-by: Stephen Warren <swarren@nvidia.com>