Add the device-tree source files for the Tegra194 Jetson Xavier NX
Developer Kit. The Xavier NX Developer Kit consists of a small form
factor system-on-module (SOM) board (part number p3668-0000) and a
carrier board (part number p3509-0000).

The Xavier NX Developer Kit SOM features a micro-SD card slot, however,
there is also a variant of the SOM available that features a 16GB eMMC.
Given that the carrier board can be used with the different SOM
variants, that have different part numbers, both the compatible string
and file name of the device-tree source file for the Developer Kit is a
concatenation of the SOM and carrier board part numbers.

Based on some initial work by Thierry Reding <treding@nvidia.com>.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Re-order Tegra194's PCIe aperture mappings to have IO window moved to
64-bit aperture and have the entire 32-bit aperture used for accessing
the configuration space. This makes it to use the entire 32MB of the 32-bit
aperture for ECAM purpose while booting through ACPI.
Signed-off-by: NVidya Sagar <vidyas@nvidia.com>
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch enables VI and CSI in device tree for Jetson Nano.
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Jetson TX1 development board has a camera expansion connector which
has 2V8, 1V8 and 1V2 supplies to power up the camera sensor on the
supported camera modules.

Camera module designed as per Jetson TX1 camera expansion connector
may use these supplies for camera sensor avdd 2V8, digital core 1V8,
and digital interface 1V2 voltages.

These supplies are from fixed regulators on TX1 carrier board with
enable control signals from I2C GPIO expanders.

This patch adds these camera supplies to Jetson TX1 device tree to
allow using these when a camera module is used.
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This is purely to make the json-schema validation tools happy because
they cannot deal with string arrays that may be in arbitrary order.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The control backbone is a simple-bus and hence its device tree node
should be named "bus@<unit-address>" according to the bindings.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Move the usb@700d0000 node to the correct place in the device tree,
ordered by unit-address.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Standardize on "pmic" as the node name for the PMIC on Tegra210 systems
and use consistent names for pinmux and GPIO hog nodes.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Device tree nodes for interrupt controllers should be named "interrupt-
controller", so rename the AGIC accordingly.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Properly indent subsequent lines so that they align with the first line.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Properly indent subsequent lines so that they align with the first line.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The AON GPIO controller on Tegra194 currently only uses a single
interrupt, so remove the extra ones.
Signed-off-by: NThierry Reding <treding@nvidia.com>

SRAM nodes should be named sram@<unit-address> to match the bindings.

While at it, also remove the unneeded, custom compatible string for
SRAM partition nodes.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The display hub on Tegra186 and Tegra194 is not a simple bus, so drop
the corresponding compatible string.
Signed-off-by: NThierry Reding <treding@nvidia.com>

It's very difficult to describe string lists that can be in arbitrary
order using the json-schema based validation tooling. Since the OS is
not going to care either way, take the easy way out and reorder these
entries to match the order defined in the bindings.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The XUSB controller doesn't need the XUSB pad controller's interrupt, so
remove it.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The address-bits and page-size properties that are currently used are
not valid properties according to the bindings. Use the address-width
and pagesize properties instead.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use the preferred {id,vbus}-gpios over the {id,vbus}-gpio properties and
fix the ordering of compatible strings (most-specific ones should come
first).
Signed-off-by: NThierry Reding <treding@nvidia.com>

On Tegra186 and later, the BPMP is responsible for enabling/disabling
the PCIe related power supplies of the pad controller and there is no
need for the operating system to control them, so they can be removed.
Signed-off-by: NThierry Reding <treding@nvidia.com>

USB PHYs must have a #phy-cells property, so add one to the Tegra USB
PHYs which don't have one.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The external memory controller found on Tegra132 is not fully compatible
with the instantiation on Tegra124, so remove the corresponding string
from the list of compatible strings.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The sor0_out clock is required to make eDP work properly.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The host1x is not a simple bus, so drop the corresponding compatible
string.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Tuple boundaries should be marked by < and > to make it clear which
cells are part of the same tuple. This also helps the json-schema based
validation tooling to properly parse this data.

While at it, also remove the "immovable" bit from PCI addresses. All of
these addresses are in fact "movable".
Signed-off-by: NThierry Reding <treding@nvidia.com>

This panel supply is always on, so this does happen to work by accident.
Make sure to properly hook up the power supply to model the dependency
correctly and so that the panel continues to operate properly even if
the supply is not always on.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The standard way to do this is to list out the regulators at the top-
level. Adopt the standard way to fix validation.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The standard way to do this is to list out the clocks at the top-level.
Adopt the standard way to fix validation.
Signed-off-by: NThierry Reding <treding@nvidia.com>

battery-name is not a documented property, so drop it to avoid
validation failures.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use the XUSB controller instead of the legacy EHCI controller to enable
USB 3.0 support.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The new json-schema based validation tools require SD/MMC controller
nodes to be named mmc. Rename all references to them.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The memory node requires a unit-address. For some boards the bootloader,
which is usually locked down, uses a hard-coded name for the memory node
without a unit-address, so we can't fix it on those boards.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The I/O and PLL supplies used for HDMI/DP have alternative names. Use
the names that are given in the hardware documentation for consistency.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The display controller's parent clock depends on the output that's
consuming data from the display controller, so it needs to be specified
as the parent of the corresponding output. The device tree bindings do
specify this, so just correct the existing device trees that get this
wrong.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Interrupt names are used to distinguish between the syncpoint and
general host1x interrupts. Make sure they are available in the DT so
that drivers can use them if necessary.
Signed-off-by: NThierry Reding <treding@nvidia.com>

While the host1x controller found on Tegra132 is the same as on Tegra124
it is good practice to also list a SoC-specific compatible string so any
SoC-specific quirks can be implemented in drivers if necessary.
Signed-off-by: NThierry Reding <treding@nvidia.com>

This interrupt can be used for the operating system to be interrupted
when certain events occur.
Signed-off-by: NThierry Reding <treding@nvidia.com>

On Tegra194, all clients of the memory subsystem can generally address
40 bits of system memory. However, bit 39 has special meaning and will
cause the memory controller to reorder sectors for block-linear buffer
formats. This is primarily useful for graphics-related devices.

Use of bit 39 must be controlled on a case-by-case basis. Buffers that
are used with bit 39 set by one device may be used with bit 39 cleared
by other devices.

Care must be taken to allocate buffers at addresses that do not require
bit 39 to be set. This is normally not an issue for system memory since
there are no Tegra-based systems with enough RAM to exhaust the 39-bit
physical address space. However, when a device is behind an IOMMU, such
as the ARM SMMU on Tegra194, the IOMMUs input address space can cause
IOVA allocations to happen in this region. This is for example the case
when an operating system implements a top-down allocation policy for IO
virtual addresses.

To account for this, describe the path that memory accesses take through
the system. Memory clients will send requests to the memory controller,
which forwards bits [38:0] of the address either to the external memory
controller or the SMMU, depending on the stream ID of the access. A good
way to describe this is using the interconnects bindings, see:

    Documentation/devicetree/bindings/interconnect/interconnect.txt

The standard "dma-mem" path is used to describe the path towards system
memory via the memory controller. A dma-ranges property in the memory
controller's device tree node limits the range of DMA addresses that the
memory clients can use to bits [38:0], ensuring that bit 39 is not used.
Signed-off-by: NThierry Reding <treding@nvidia.com>
---
Changes in v4:
- add additional entries for interconnect-names to match interconnects
- add EMC as destination for interconnect paths

Changes in v3:
- add missing interconnect properties for VIC

Changes in v2:
- use memory client IDs instead of stream IDs (Mikko Perttunen)
Signed-off-by: NThierry Reding <treding@nvidia.com>

The interface used by clients of the memory controller can be configured
in a number of different ways. Describe this path using the interconnect
bindings to enable the configuration of these parameters.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The SDHCI on Tegra210 is in fact not compatible with the one found on
Tegra124. Remove the extra compatible string to reflect that.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The SDHCI on Tegra194 is in fact not compatible with the one found on
Tegra186. Remove the extra compatible string to reflect that.
Signed-off-by: NThierry Reding <treding@nvidia.com>