ASoC: tegra: add runtime PM to resume functions

Tegra HW needs clocks etc. active when touching registers. Make sure they
are active during resume, by calling pm_runtime_get_sync() before touching
HW.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ASoC: dapm: check suspend state in dapm_dai_check_power()

Currently, when the system enters suspend with audio playing, since the
DAI widgets are active, the associated CODEC is considered active, and
hence is not transition into a low-power bias state as the system
suspends. This likely causes audio failure after resume, since the CODEC
power has quite possibly been removed during suspend, and the bias level
transitions in the CODEC driver are needed to recover from this. At the
very least, this issue likely causes warnings in the kernel log due to
the CODEC being left on over the suspend transition.

To solve this, modify dapm_dai_check_power() not to consider DAI widgets
active if the system is entering suspend.

Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
dtc: ensure #line directives don't consume data from the next line

Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming literal 1234 as part of the #line processing, thus removing it
from the cell data).

Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.

Convert all instances of {WS}, even though the other instances should be
irrelevant for any well-formed #line directive. This is done for
consistency and ultimate safety.

This is a port of upstream dtc commit a1ee6f0 (with same subject) to the
kernel's copy of dtc.

Reported-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
usb: phy: export ulpi_viewport_access_ops

In order to build a ULPI PHY driver as a module, this symbol needs to
be exported.

Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
[swarren, reworked Manjunath's patches to split them more logically]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: phy: add MODULE_LICENSE to phy-tegra-usb.c

When this file is built as a module, it needs a MODULE_LICENSE in order
to access many exported symbols.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
USB: EHCI: expand struct ehci_driver_overrides

Some EHCI HCD drivers may need to override additional fields in struct
hc_driver, such as map_urb_for_dma, unmap_urb_for_dma, hub_control. Add
fields to struct ehci_driver_overrides to allow them to do so.

These new overrides will be used at least by the Tegra EHCI driver.

Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
[swarren, reworked Manjunath's patches to split them more logically]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
USB: EHCI: export symbols for ehci-hcd sub-drivers

In order to split ehci-hcd.c into separate modules, various symbols must
be exported. Also, rename the symbols to add an ehci_ prefix, to avoid
any naming clashes.

Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
[swarren, reworked Manjunath's patches to split them more logically]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
USB: EHCI: fix circular dependency in Tegra modules

The Tegra EHCI driver directly calls various functions in the Tegra USB
PHY driver. The reverse is also true; the PHY driver calls into the EHCI
driver. This is problematic when the two are built as modules.

The calls from the PHY to EHCI driver were originally added in commit
bbdabdb "usb: add APIs to access host registers from Tegra PHY", for the
following reasons:

1) The register being touched is an EHCI register, so logically only the
   EHCI driver should touch it.
2) (1) implies that some locking may be needed to correctly implement the
   r/m/w access to this shared register.
3) We were expecting to pass only the PHY register space to the Tegra PHY
   driver, and hence it would not have access to touch the shared
   registers.

To solve this, that commit added functions in the EHCI driver to touch the
shared register on behalf of the PHY driver.

In practice, we ended up not having any locking in the implementaiton of
those functions, and I've been led to believe this is safe. Equally, (3)
did not happen either. Hence, it is possible for the PHY driver to touch
the shared register directly.

Given that, this patch moves the code to touch the shared register back
into the PHY driver, to eliminate the module problems. If we actually
need locking or co-ordination in the future, I propose we put the lock
support into some pre-existing core module, or into a third separate
module, in order to avoid the circular dependencies.

I apologize for my contribution to code churn here.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
USB: EHCI: make ehci-tegra a separate driver

Separate the Tegra on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.

Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
[swarren, reworked Manjunath's patches to split them more logically,
minor re-order of added lines to better match layout of other split-up
HCD drivers and existing code, add MODULE_DEVICE_TABLE, fix
MODULE_LICENSE.]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: call disable_nonboot_cpus() from machine_shutdown()

On Tegra at least, this change allows kexec to work with SMP enabled.
Without this,  machine_shutdown() simply puts all CPUs into a loop. If
the code of that loop is over-written, the CPUs may hang or crash (which
I do observe in practice), or cause the kexec'd kernel not to be able to
initialize them.

This fix has the added benefit that the kexec always happens on the boot
CPU, and thus kexec mirrors the initial kernel boot as much as possible.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Will Deacon <will.deacon@arm.com>
BROKEN: ARM: tegra: trimslice: enable DVI port

The DVI port is driven from the "RGB" port, via a DVI encoder chip.

BROKEN:
* Booting with just DVI plugged in yields a signal the monitor can't sync to.
* Booting with HDMI, then moving the cable to DVI yields incorrect colors and
  a lower resolution than the panel's native resolution (1024x768@67Hz!).

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
[swarren: extracted from a larger patch by Thierry]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
BROKEN: ARM: tegra: cardhu: enable HDMI port

BROKEN because the only bootloaders we have already enable the LCD scanout,
and dual-display stresses the memory bandwidth too much, because the memory
controller programming is way off on Cardhu right now.

Signed-off-by: Mark Zhang <markz@nvidia.com>
[swarren: extracted from a larger patch by Mark]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Revert "BROKEN: ARM: tegra: cardhu: enable HDMI port"

This reverts commit 17c37e0079ade1e6140002dd4ef0f79e08f185c9.
HACK: ARM: dt: tegra: cardhu: Enable LCD panel

HACK: it's missing any of the panel/backlight control GPIOs etc.

Signed-off-by: Mark Zhang <markz@nvidia.com>
[swarren: extracted from a larger patch by Mark]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
LOCAL HACK: tegra_defconfig changes

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: bluetooth testing hacks for Cardhu

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ASoC: add RT5640 CODEC driver

Note: This driver was originally written by Johnny Hsu at Realtek
according to comment in the file. Hence, the git author field contains
Johnny's name. However, the driver was provided as a .zip file without
any signed-off-by line. When I contacted Realtek to obtain one, Bard
responded with his, hence it is included below. Since they work for the
same company, I assume this is acceptable.

This driver is based on a copy Realtek gave NVIDIA over 2 years ago, plus
some fixes NVIDIA applied internally, plus various cleanup I (swarren)
performed during upstreaming. Realtek does have a newer base version of
this driver, but the speakers don't appear to work in that version, so
I ignored it for now. Hopefully, the changes in that driver will trickle
upstream after this.

I (swarren) made the following changes relative to downstream, so I
should be blamed for:
* Replaced separate HPOL MIX and HPOR MIX with a single HPO MIX, since
  there is only 1 control in HW. This change was taken from Realtek's
  latest driver.
* Replaced SND_SOC_DAPM_MICBIAS with SND_SOC_DAPM_SUPPLY, although I
  can't test this yet.
* Renamed Mono outputs to MONO to match documentation and be consistent
  with all other inputs/outputs. Renamed micbias inputs to MICBIAS too.
* Trimmed down the register init table to remove entries that duplicate
  ASoC widgets. Added a couple missing widgets (Speaker Playback Switch,
  Speaker Channel Switch, HP Channel Switch) to support this.
* Removed support for RT5643, since I can't test that.
* Removed support for rt5640_headset_detect(), since I can't test it, and
  the style doesn't seem to match what I've seen in other CODECs.
* Update probe() to call rt5640_set_bias_level() to avoid duplicate code.
* Minor changes to adapt to recent kernel changes:
  * Make use of module_i2c_driver.
  * Remove use of devinit/devexit.
* Removed a bunch of ifdef'd and dead code.
* Formatting, checkpatch, and warning fixes.

I've tested playback to the speaker and headphone outputs, but not:
* The "OUT" output.
* Any capture path.

Cc: Bard Liao <bardliao@realtek.com>
Cc: Johnny Hsu <johnnyhsu@realtek.com>
Cc: Oder Chiou <oder_chiou@realtek.com>
Cc: Flove <flove@realtek.com>
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2:
* Make use of new "mixer control sharing" feature for HPO MIX L/R.

Mark, a couple questions:
* Is the custom index_reg device attr file OK, or should I remove that?
* Do new CODEC drivers have to use regmap directly, or is using the ASoC
  IO system still OK?
ASoC: tegra: add tegra+RT5640 machine driver

FIXME: describe this

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: enable audio on Dalmore

Dalmore uses the RT5640 audio CODEC. Instantiate this on the I2C bus.
Enable the relevant Tegra I2C controller. Add the top-level "sound" node
to hook everything together, and provide a "sound card" device.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: defconfig updates for audio on Dalmore

Enable the ASoC machine driver that is required for audio on Dalmore.

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