APPLIED: pinctrl: clean up pinconfig-generic documentation

Reword the section of pinctrl-bindings.txt that describes generic
properties that pinctrl bindings may use. The aim is to make the text
clearer, and more explicitly call out the responsibility of individual
bindings that use the generic properties to define which of the
properties are used, and how.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: pinctrl: add generic pins and functions properties

pinctrl bindings can benefit from generic property names that define
which pins a "pin configuration node" affects, and which mux function
to select onto those pins. Document new properties for this purpose so
that other bindings may refer to them.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Define the arguments that the pins and functions properties take.
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>
---
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.
of: move documentation of of_parse_phandle_with_args

Commit bd69f73 "of: Create function for counting number of phandles in
a property" renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved, leaving it apparently documenting
the newly renamed function.

Move the documentation so that it is adjacent to the function it
documents.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
of: introduce of_parse_phandle_with_fixed_args

This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
---
v3: s/cells_count/cell_count, add missing braces per coding style
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
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.
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>