arm64: tegra: Rename cbb@0 to bus@0 on Tegra194

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: Th

arm64: tegra: Rename cbb@0 to bus@0 on Tegra194

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: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Fix indentation in Tegra194 device tree

Properly indent subsequent lines so that they align with the first line.

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

arm64: tegra: Remove unused interrupts from Tegra194 AON GPIO

The AON GPIO controller on Tegra194 currently only uses a single
interrupt, so remove the extra ones.

Signed-off-by: Thierry Reding <tr

arm64: tegra: Remove unused interrupts from Tegra194 AON GPIO

The AON GPIO controller on Tegra194 currently only uses a single
interrupt, so remove the extra ones.

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

show more ...

arm64: tegra: Use standard names for SRAM nodes

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

While at it, also remove the unneeded, custom compatible string for
SRAM partit

arm64: tegra: Use standard names for SRAM nodes

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: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Do not mark display hub as simple bus

The display hub on Tegra186 and Tegra194 is not a simple bus, so drop
the corresponding compatible string.

Signed-off-by: Thierry Reding <treding

arm64: tegra: Do not mark display hub as simple bus

The display hub on Tegra186 and Tegra194 is not a simple bus, so drop
the corresponding compatible string.

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

show more ...

arm64: tegra: Remove XUSB pad controller interrupt from XUSB node

The XUSB controller doesn't need the XUSB pad controller's interrupt, so
remove it.

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

arm64: tegra: Remove XUSB pad controller interrupt from XUSB node

The XUSB controller doesn't need the XUSB pad controller's interrupt, so
remove it.

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

show more ...

arm64: tegra: Do not mark host1x as simple bus

The host1x is not a simple bus, so drop the corresponding compatible
string.

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

arm64: tegra: Use proper tuple notation

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

arm64: tegra: Use proper tuple notation

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: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Rename sdhci nodes to mmc

The new json-schema based validation tools require SD/MMC controller
nodes to be named mmc. Rename all references to them.

Signed-off-by: Thierry Reding <tre

arm64: tegra: Rename sdhci nodes to mmc

The new json-schema based validation tools require SD/MMC controller
nodes to be named mmc. Rename all references to them.

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

show more ...

arm64: tegra: Add interrupt-names for host1x

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 u

arm64: tegra: Add interrupt-names for host1x

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: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Add interrupt for Tegra194 memory controller

This interrupt can be used for the operating system to be interrupted
when certain events occur.

Signed-off-by: Thierry Reding <treding@nv

arm64: tegra: Add interrupt for Tegra194 memory controller

This interrupt can be used for the operating system to be interrupted
when certain events occur.

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

show more ...

arm64: tegra: Describe interconnect paths on Tegra194

On Tegra194, all clients of the memory subsystem can generally address
40 bits of system memory. However, bit 39 has special meaning and will
ca

arm64: tegra: Describe interconnect paths on Tegra194

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: Thierry 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: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Remove extra compatible for Tegra194 SDHCI

The SDHCI on Tegra194 is in fact not compatible with the one found on
Tegra186. Remove the extra compatible string to reflect that.

Signed-o

arm64: tegra: Remove extra compatible for Tegra194 SDHCI

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: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Fix flag for 64-bit resources in 'ranges' property

Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.

Fixes: 2602c32f15e7 ("arm6

arm64: tegra: Fix flag for 64-bit resources in 'ranges' property

Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.

Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Add XUDC node on Tegra194

Tegra194 has one XUSB device mode controller which can be operated in HS
and SS modes. Add a DT node for this XUSB device mode controller.

Signed-off-by: Nag

arm64: tegra: Add XUDC node on Tegra194

Tegra194 has one XUSB device mode controller which can be operated in HS
and SS modes. Add a DT node for this XUSB device mode controller.

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

show more ...

arm64: tegra: Add PCIe endpoint controllers nodes for Tegra194

Add endpoint mode controllers nodes for the dual mode PCIe controllers
present in Tegra194 SoC.

Signed-off-by: Vidya Sagar <vidyas@nvi

arm64: tegra: Add PCIe endpoint controllers nodes for Tegra194

Add endpoint mode controllers nodes for the dual mode PCIe controllers
present in Tegra194 SoC.

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

show more ...

arm64: tegra: Add XUSB and pad controller on Tegra194

Adds the XUSB pad and XUSB controllers on Tegra194.

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

arm64: tegra: Fix Tegra194 PCIe compatible string

If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled
then this can cause the kernel to incorrectly probe the generic
designware PC

arm64: tegra: Fix Tegra194 PCIe compatible string

If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled
then this can cause the kernel to incorrectly probe the generic
designware PCIe platform driver instead of the Tegra194 designware PCIe
driver. This causes a boot failure on Tegra194 because the necessary
configuration to access the hardware is not performed.

The order in which the compatible strings are populated in Device-Tree
is not relevant in this case, because the kernel will attempt to probe
the device as soon as a driver is loaded and if the generic designware
PCIe driver is loaded first, then this driver will be probed first.
Therefore, to fix this problem, remove the "snps,dw-pcie" string from
the compatible string as we never want this driver to be probe on
Tegra194.

Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

arm64: tegra: Add fuse/apbmisc node on Tegra194

This commit adds Tegra194 fuse and apbmisc device nodes.

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

arm64: tegra: Add the memory subsystem on Tegra194

The memory subsystem on Tegra194 encompasses both the memory and
external memory controllers. The EMC is represented as a subnode of the
MC and a r

arm64: tegra: Add the memory subsystem on Tegra194

The memory subsystem on Tegra194 encompasses both the memory and
external memory controllers. The EMC is represented as a subnode of the
MC and a ranges property is used to describe the register ranges.

A dma-ranges property is also added to describe that all memory clients
can address up to 39 bits using the memory controller client interface
(MCCIF), unless otherwise limited by the DMA engines of the hardware. A
memory client can technically use 40 bits of addresses, but the memory
controller on Tegra194 uses bit 39 to determine the XBAR format used to
access memory. Use of this bit needs to be explicitly controlled by the
operating system drivers for devices that can use this on-the-fly format
conversion. Using the dma-ranges property prevents the operating system
from using the bit implicitly, for example in I/O virtual address
mappings.

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

show more ...

arm64: tegra: Assume no CLKREQ presence by default

Although Tegra194 has support for CLKREQ sideband signal and P2972
has routing of the same till the slot, it is the case most of the time
that the

arm64: tegra: Assume no CLKREQ presence by default

Although Tegra194 has support for CLKREQ sideband signal and P2972
has routing of the same till the slot, it is the case most of the time
that the connected device doesn't have CLKREQ support. Hence, it makes
sense to assume that there is no CLKREQ support by default and it can
be enabled on need basis when a card with CLKREQ support is connected.

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

show more ...

arm64: tegra: Fix compatible string for EQOS on Tegra194

The EQOS Ethernet controller found on Tegra194 is compatible with its
predecessor or Tegra186. However, it is an established practice to add

arm64: tegra: Fix compatible string for EQOS on Tegra194

The EQOS Ethernet controller found on Tegra194 is compatible with its
predecessor or Tegra186. However, it is an established practice to add
a compatible string for the most recent generation of the SoC as well,
just in case some incompatibilities or bugs are later discovered.

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

show more ...

arm64: tegra: Fix base address for SOR1 on Tegra194

The SOR1 hardware block's registers start at physical address 0x15b40000
as correctly specified by the unit-address, but the reg property lists a

arm64: tegra: Fix base address for SOR1 on Tegra194

The SOR1 hardware block's registers start at physical address 0x15b40000
as correctly specified by the unit-address, but the reg property lists a
wrong value, likely because it was copy-and-pasted from SOR0 but not
correctly updated.

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

show more ...

arm64: tegra: Add unit-address for ACONNECT on Tegra194

The ACONNECT complex starts at physical address 0x2900000, so give it a
unit-address to comply with standard naming practices checked for by t

arm64: tegra: Add unit-address for ACONNECT on Tegra194

The ACONNECT complex starts at physical address 0x2900000, so give it a
unit-address to comply with standard naming practices checked for by the
device tree compiler.

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

show more ...

arm64: tegra: Add unit-address for CBB on Tegra194

The control back-bone (CBB) starts at physical address 0, so give it a
unit-address to comply with standard naming practices checked for by the
dev

arm64: tegra: Add unit-address for CBB on Tegra194

The control back-bone (CBB) starts at physical address 0, so give it a
unit-address to comply with standard naming practices checked for by the
device tree compiler.

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

show more ...