gpio: clean up gpio-ranges documentation

This change makes documentation of the the gpio-ranges property shorter
and more succinct, more consistent with the style of the rest of the
document, and not mention Linux-specifics such as the API
pinctrl_request_gpio(); DT binding documents should be OS independant
where at all possible. As part of this, the gpio-ranges property's format
is described in BNF form, in order to match the rest of the document.

This change also deprecates the #gpio-range-cells property. Such
properties are useful when one node references a second node, and that
second node dictates the format of the reference. However, that is not
the case here; the definition of gpio-ranges itself always dictates its
format entirely, and hence the value #gpio-range-cells must always be 3,
and hence there is no point requiring any referenced node to include
this property. The only remaining need for this property is to ensure
compatibility of DTs with older SW that was written to support the
previous version of the binding.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
---
v5:
* Re-ordered patches so all of patches first, then gpio patches after.
v4:
* Mention #gpio-range-cells as being deprecated, rather than removing all
  documentation of that property. This allows DTs to be written in a
  backwards-compatible way if desired, and also allows older DTs to be
  interpreted fully using the latest documentation.
v3:
* Mention BNF in commit description.
* Fixed typo.
* Dropped patch that removed the deprecated property from *.dts, since
  it's required to boot older kernels.

Patches 2-4 need to be applied in the same branch, since they all build
upon each-other.
gpio: implement gpio-ranges binding document fix

Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
ARM: kexec: validate CPU hotplug support

Architectures should fully validate whether kexec is possible as part of
machine_kexec_prepare(), so that user-space's kexec_load() operation can
report any problems. Performing validation in machine_kexec() itself is
too late, since it is not allowed to return.

Prior to this patch, ARM's machine_kexec() was testing after-the-fact
whether machine_kexec_prepare() was able to disable all but one CPU.
Instead, modify machine_kexec_prepare() to validate all conditions
necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
succeeded, yet disabling the CPUs didn't actually work.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
v2: Fix compilation issue when !CONFIG_HOTPLUG_CPU
ARM: allow DEBUG_UNCOMPRESS for Tegra

DEBUG_UNCOMPRESS was previously disallowed for Tegra due to tegra.S's
use of global data that was not linked into the decompressor. Solve this
by declaring this symbol in tegra.S when it is being built into the
decompressor. For the kernel proper, leave the declaration in
mach-tegra/common.c as explained in the comment.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
---
v2: Don't select DEBUG_UNCOMPRESS with DEBUG_TEGRA_UART unless
    !ZBOOT_ROM. Add notes on ZBOOT_ROM to comment.
ARM: tegra: use simplefb for Tegra20 boards with LCDs

Signed-off-by: Stephen Warren <swarren@nvidia.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>
HACK: Attempt to get DMICs working
clk: tegra30: Don't wait for PLL_U lock bit

The lock bit on PLL_U does not seem to be working correctly and
sometimes never gets set when waiting for the PLL to come up.
Remove the TEGRA_PLL_USE_LOCK flag to use a constant delay.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: DTS: tegra: Add USB entries for Tegra30

Add device tree entries for the 3 USB controllers and PHYs and
enable the third controller on Cardhu and Beaver boards.

Fix VBUS regulator entries on Beaver. The GPIO pins were wrong.
Also, internal pullups need to be enabled on those pins.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: dts: USB for Tegra114 Dalmore

Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: host: add has_tdi_phy_lpm capability bit

The has_hostpc capability bit indicates that the host controller has the
HOSTPC register extensions, but at the same time enables clock disabling
power saving features with the PHY Low Power Clock Disable (PHCD) bit.

However, some host controllers have the HOSTPC extensions but don't
support the low-power feature, so the PHCD bit must not be set on those
controllers. Add a separate capability bit for the low-power feature
instead, and change all existing users of has_hostpc to use this new
capability bit.

The idea for this commit is taken from an old 2012 commit that never got
merged ("disociate chipidea PHY low power suspend control from hostpc")

Inspired-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: phy: tegra: Fix wrong PHY parameters

Some of the PHY parameters are not set according to the TRMs:

- UTMIP_FS_PREABMLE_J should be set, not cleared
- UTMIP_XCVR_LSBIAS_SEL should be cleared, not set
- UTMIP_PD_CHRG should be set in host mode and cleared in device mode
- UTMIP_XCVR_SETUP is a two-part field; the upper bits were not set
  properly

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: phy: tegra: Tegra30 support

The Tegra30 USB PHY is a bit different than the Tegra20 PHY:

- The EHCI controller supports the HOSTPC register extension, and some
  of the fields that the PHY needs to modify (PHCD and PTS) have moved
  to the new HOSTPC register.
- Some of the UTMI PLL configuration registers have moved from the USB
  register space to the Clock-And-Reset controller space. In Tegra30
  the clock driver is responsible for configuring the UTMI PLL.
- The USBMODE register must be explicitly written to enter host mode.
- Certain PHY parameters need to be programmed for optimal signal
  quality. Support for this will be added in the next patch.

The new tegra_phy_soc_config structure is added to describe the
differences between the SoCs.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Documentation: New DT parameters for tegra30-usb-phy

Document the new device tree parameters for Tegra30 USB PHY.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: phy: tegra: Program new PHY parameters

The Tegra30 TRM recommends configuration of certain PHY parameters for
optimal quality. Program the following registers based on device tree
parameters:

- UTMIP_XCVR_HSSLEW: HS slew rate control.
- UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
- UTMIP_HSDISCON_LEVEL: HS disconnect detector level.

These registers exist in Tegra20, but programming them hasn't been
necessary, so these parameters won't be set on Tegra20 to keep the
device trees backward compatible.

Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses
instead of a software-programmed value, as the optimal value can
vary between invidual boards. The boolean property
nvidia,xcvr-setup-use-fuses can be used to enable this behaviour.

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