LINUX-NEXT FIX: irq_work: Remove BUG_ON in irq_work_run()

Because of a collision with 8d056c48e486 ("CPU hotplug, smp: flush any
pending IPI callbacks before CPU offline"), which ends up calling
hotplug_cfd()->flush_smp_call_function_queue()->irq_work_run(), which
is not from IRQ context.

And since that already calls irq_work_run() from the hotplug path,
remove our entire hotplug handling.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-busatzs2gvz4v62258agipuf@git.kernel.org
[swarren, removed static from one function to compile]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: remove pinmux setup from Tegra124 boards

The defined mechanism for programming the Tegra pinmux is to perform all
of the following at once:

- Set the CLAMP_INPUTS_WHEN_TRISTATED PMC register bit.
- Set up any GPIO pins to their "initial" state.
- Program all pinmux settings in one go.

Other methods such as:

- Not setting CLAMP_INPUTS_WHEN_TRISTATED.
- Not setting GPIOs to their "initial" state before programming the
  pinmux settings of the related pin, in particular the mux function.
- Not programming the entire pinmux at once, in order to avoid
  possible conflicting settings.

... are not qualified or supported by NVIDIA ASIC/syseng. They could
cause glitches or undesired output levels on some pins, or controller
malfunction.

While we've been getting away with doing something different on many
Tegra boards without issue, I believe we've just been getting lucky.
I'd like to switch all Tegra124 systems to the correct scheme now so
they provide the right example to follow, and require that any new
boards we support upstream work in the same fashion.

While it would be nice to update boards containing older SoCs for
consistency, I don't anticipate doing so. It's too much churn to change
at this time. At least with all Tegra124 boards converted, the most
recent boards provide the correct example.

Since the bootloader needs to reprogram the pinmux to access certain
peripherals, it must program the entire pinmux due to the supported
rules above. As such, there is no need to program any part of the pinmux
from the kernel, unless dynamic pinmuxing is used. Hence, this change
removes all static pinmux from all Tegra124 board DTs.

The following U-Boot commits fully initialize the pinmux:

Jetson TK1: 4ff213b8e478 ARM: tegra: clamp inputs on Jetson TK1

Venice2: 3365479ce78a ARM: tegra: Venice2 pinmux spreadsheet updates

Without those commits, the only fallout I see from this change is that
HDMI on Venice2 no longer works. Given the very small user-base of this
platform, I feel that requiring a bootloader update is reasonable.

Cc: Andrew Bresticker <abrestic@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Dylan Reid <dgreid@chromium.org>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Input: atmel_mxt_ts - Set pointer emulation on touchpads

Touchpads are pointers, so make sure to pass the correct values to
input_mt_report_pointer_emulation(). Without this, tap-to-click doesn't
work.

There used to be an explicit is_tp field indicating whether the device
is a touchpad or touch screen. Not-yet-committed patch "Input:
atmel_mxt_ts - improve T19 GPIO keys handling" removed it, and replaced
usage with pdata->t19_num_keys instead. Hence, this commit does the same.
I don't know enough about T19 GPIO keys to know if this is the correct
data to drive this decision.

Signed-off-by: Benson Leung <bleung@chromium.org>
[swarren, reworked commit for upstream, and rewrote the commit description
since the downstream version concentrated on patch rebase history rather
than the functionality]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Input: atmel_mxt_ts: define a device tree binding

This document describes how to represent an Atmel MXT touchpad in device
tree.

The device may show up in bootloader mode if reset by SW, or if
configuration/firmware is missing. Or, it may present itself as the final
touchpad device. These modes have different I2C addresses, and hence
different I2C nodes with different compatible values representing their
feature-set.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Input: atmel_mxt_ts: implement device tree parsing

If platform data is missing, and the device was instantiated via device
tree, parse the DT to generate the platform data.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: add touchpad to Venice2 DT

Venice2 contains an Atmel MXT touchpad. Add an I2C node for it to DT.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: enable Atmel touchpad in defconfig

This driver is used on Venice2 for the touchpad.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: add light sensor to Venice2 DT

FIXME: Initialization often fails with the errors below, but sometimes
succeeds. dmesg|grep -i isl:
[    1.765974] isl29018 1-0044: No cache defaults, reading back from HW
[    1.772624] isl29018 1-0044: regmap initialization failed: -121
[    1.778637] isl29018: probe of 1-0044 failed with error -121

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: rebuild tegra_defconfig on next-20140623

This makes it easier to create isolated defconfig patches

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: rebuild multi_v7_defconfig on next-20140616

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>
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>
clk: tegra124: Enable hda to hdmi clocks

Add the clocks used for HDMI audio played through the HDA controller.
Initialize the codec clock to 48Mhz and the HDA clock to 102MHz per
the TRM.

Signed-off-by: Dylan Reid <dgreid@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
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>
drm/tegra: hdmi - calculate HDMI audio CTS/N/AVAL values

The current table-drive approach for determining the CTS/N/AVAL values
required for HDMI audio limits audio availability to a small set of pixel
clock frequencies. Allow audio in other cases by calculating the CTS and N
value dynamically.

FIXME: This stops hdmi->dvi being set to true due to audio failure, which
then enables a bunch of other code. This breaks at least some display modes.

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