ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables

This pinmux tables currently omit any configuration for PCIe clk_req,
wake, and rst pins, which in turn causes intermittent failures in
U-Boot's PCIe support. Import an updated version of the pinmux tables
which rectifies this.

(While I'm still hoping to remove the pinmux tables from DTs for
Tegra124+ devices, while they're still here, they may as well be
complete and correct).

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>
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>
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>
Input: atmel_mxt_ts - don't double-unregister input dev on rmmod

Both mxt_free() and mxt_free_object_table() unregister the input device
unconditionally, yet mxt_free() calls mxt_free_object_table(). This
results in a double-unregister, and associated kernel crashes. Remove the
duplicate call from mxt_free(). Also, guard the unregister call in
mxt_free_object_table() so that if the input device was never created and
registered at all, no attempt is made to unregister it.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
resource: Add device-managed request/release_resource()

Provide device-managed implementations of the request_resource() and
release_resource() functions. Upon failure to request a resource, the
new devm_request_resource() function will output an error message for
consistent error reporting.

Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
PCI: tegra: Implement a proper resource hierarchy

Currently the resource hierarchy generated from the PCIe host bridge is
completely flat:

	$ cat /proc/iomem
	00000000-00000fff : /pcie-controller@00003000/pci@1,0
	00003000-000037ff : pads
	00003800-000039ff : afi
	10000000-1fffffff : cs
	28000000-28003fff : r8169
	28004000-28004fff : r8169
	...

The host bridge driver doesn't request all the resources that are used.
Windows allocated to each of the root ports aren't tracked, so there is
no way for resources allocated to individual devices to be matched up
with the correct parent resource by the PCI core.

This patch addresses this in two steps. It first takes the union of all
regions associated with the PCIe host bridge (control registers, root
port registers, configuration space, I/O and prefetchable as well as
non-prefetchable memory regions) and uses it as the new root of the
resource hierarchy.

Subsequently, regions are allocated from within this new root resource
so that the resource tree looks much more like what's expected:

	# cat /proc/iomem
	00000000-3fffffff : /pcie-controller@00003000
	  00000000-00000fff : /pcie-controller@00003000/pci@1,0
	  00003000-000037ff : pads
	  00003800-000039ff : afi
	  10000000-1fffffff : cs
	  20000000-27ffffff : non-prefetchable
	  28000000-3fffffff : prefetchable
	    28000000-280fffff : PCI Bus 0000:01
	      28000000-28003fff : 0000:01:00.0
	        28000000-28003fff : r8169
	      28004000-28004fff : 0000:01:00.0
	        28004000-28004fff : r8169
	...

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
PCI: tegra: Clear CLKREQ# enable on port disable

When a root port is disabled, disable the CLKREQ# signal if available.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
PCI: tegra: Fix extended configuration space mapping

The 16 chunks of 64 KiB that need to be stitched together to make up the
configuration space for one bus (1 MiB) are located 24 bits (== 16 MiB)
apart in physical address space. This is determined by the start of the
extended register field (bits 24-27) in the physical mapping.

Signed-off-by: Peter Daifuku <pdaifuku@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
PCI: tegra: Make sure the PCIe PLL is really reset

Depending on the prior state of the controller, the PLL reset may not be
pulsed. Clear the register bit and set it after a small delay to ensure
that the PLL is really reset.

Signed-off-by: Eric Yuen <eyuen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
PCI: tegra: Add Tegra124 support

The PCIe controller on Tegra124 has two root ports that can be used in a
x4/x1 or x2/x1 configuration and can run at PCIe 2.0 link speeds (up to
5 GT/s). The PHY programming has been moved into a separate controller,
so the driver now needs to request an external PHY referenced using the
device tree.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: tegra124: Add PCIe support

Add the PCIe controller device tree node and hook up the PCIe PHY from
the XUSB pad controller.

Signed-off-by: Thierry Reding <treding@nvidia.com>
ARM: tegra: jetson-tk1: Enable PCIe support

Enable both PCIe ports, one of which is connected to an onboard ethernet
chip, whereas the other goes to a miniPCIe slot.

Signed-off-by: Thierry Reding <treding@nvidia.com>