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>
HACK: Attempt to get DMICs working
ARM: tegra: enable audio on Beaver

FIXME: Need to run "gpio set 186" in U-Boot before booting the kernel,
to enable LDO1_EN to get the CODEC to show up on the I2C bus.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: disable LP2 cpuidle state if PCIe is enabled

Tegra20 HW appears to have a bug such that PCIe device interrupts, whether
they are legacy IRQs or MSI, are lost when LP2 is enabled. To work around
this, simply disable LP2 if the PCI driver and DT node are both enabled.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Set state.disable rather than fiddling with .state_count. This is
more flexible.