Cadence IP in J721E supports a maximum of 32 outbound regions. However
commit 4e583388 ("arm64: dts: ti: k3-j721e-main: Add PCIe device
tree nodes") incorrectly added this as 16 outbound regions. Now that
"cdns,max-outbound-regions" is an optional property with default value
as 32, remove "cdns,max-outbound-regions" from endpoint DT node.
(Since this doesn't impact existing functionality, it need not be
backported to older kernels).
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210105151421.23237-2-kishon@ti.com

Add support for UHS modes for the SD card connected at sdhci1. This
involves adding regulators for voltage switching and power cycling the
SD card and removing the no-1-8-v property.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20201129175223.21751-3-nsekhar@ti.com

Add output tap delay values as given in the latest Data Manual[1],
SPRSP36E, revised December 2019.

[1] https://www.ti.com/lit/gpn/tda4vmSigned-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20201129175223.21751-2-nsekhar@ti.com

There are couple of places where INTA interrupt controller
lacks #interrupt-cells property. This leads to warnings of
the type:

arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:147.51-156.5: Warning (interrupt_provider): /bus@100000/main-navss/interrupt-controller@33d00000: Missing #interrupt-cells in interrupt provider

when building TI device-tree files with W=2 warning level.
Fix these.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201127210128.9151-1-nsekhar@ti.com

J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3

The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
usable with the J7200 SOM.

Correct the expander name from exp4 to exp3 and at the same time add the
line names as well.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201120073533.24486-3-peter.ujfalusi@ti.com

The J7200 SOM have additional io expander which is used to control several
SOM level muxes to make sure that the correct signals are routed to the
correct pin on the SOM <-> CPB connectors.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201120073533.24486-2-peter.ujfalusi@ti.com

Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the J7200 SoCs to the J7200 common
processor board. These include the R5F remote processors in the dual-R5F
clusters in the MCU domain (MCU_R5FSS0) and the MAIN domain (MAIN_R5FSS0).
These sub-mailbox nodes utilize the System Mailbox clusters 0 and 1. All
the remaining mailbox clusters are currently not used on A72 core, and
so are disabled. The nodes are added in the k3-j7200-som-p0.dtsi file
to co-locate these alongside future reserved-memory nodes required for
remoteprocs.

The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. A sub-mailbox node is added
for each of the R5F cores to accommodate the R5F processor sub-systems
running in Split mode. Only the sub-mailbox node for the first R5F core in
each cluster is used in case of Lockstep mode for that R5F cluster.

NOTE:
The GIC_SPI interrupts to be used are dynamically allocated and managed
by the System Firmware through the ti-sci-intr irqchip driver. So, only
valid interrupts that are used by the sub-mailbox devices (each cluster's
User 0 IRQ output) are enabled. This is done to minimize the number of
NavSS Interrupt Router outputs utilized.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NPraneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/20201026232637.15681-4-s-anna@ti.com

The J7200 Main NavSS block contains a Mailbox IP instance with
multiple clusters, and follows the same integration style as on
J721E SoCs.

Add all the Mailbox clusters as their own nodes under the MAIN
NavSS interconnect node instead of creating an almost empty parent
node for the new K3 mailbox IP and the clusters as its child nodes.
All these nodes are enabled by default in the base dtsi file, but
any cluster that does not define any child sub-mailbox nodes
should be disabled in the corresponding board dts files.

NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A72 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NPraneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/20201026232637.15681-3-s-anna@ti.com

The Main NavSS block on J7200 SoCs contains a HwSpinlock IP instance that
is same as the IP on AM65x and J721E SoCs. Add the DT node for this on
J7200 SoCs. The node is present within the Main NavSS block, and is added
as a child node under the main_navss interconnect node.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NPraneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/20201026232637.15681-2-s-anna@ti.com

Follow the device tree standards that states to set the
status="reserved" if an device is operational, but used by a non-linux
firmware in the system.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Acked-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20201113211826.13087-6-nm@ti.com

The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the board dts.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Link: https://lore.kernel.org/r/20201113211826.13087-5-nm@ti.com

The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the SoC dtsi.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Link: https://lore.kernel.org/r/20201113211826.13087-4-nm@ti.com

The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.

In general, after a few rounds of discussions [1] there are few
options one could take when dealing with SoC dtsi and board dts

a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
   to prevent messy board files, when more boards are added per SoC, we
   optimize and disable commonly un-used nodes in board-common.dtsi
b. SoC dtsi disables all hardware dependent nodes by default and board
   dts files enable nodes based on a need basis.
c. Subjectively pick and choose which nodes we will disable by default
   in SoC dtsi and over the years we can optimize things and change
   default state depending on the need.

While there are pros and cons on each of these approaches, the right
thing to do will be to stick with device tree default standards and
work within those established rules. So, we choose to go with option
(a).

Lets cleanup defaults of j721e SoC dtsi before this gets more harder
to cleanup later on and new SoCs are added.

The only functional difference between the dtb generated is
status='okay' is no longer necessary for mcasp10 and depends on the
default state.

NOTE: There is a known risk of omission that new board dts developers
might miss reviewing both the board schematics in addition to all the
DT nodes of the SoC when setting appropriate nodes status to disable
or reserved in the board dts. This can expose issues in drivers that
may not anticipate an incomplete node (example: missing appropriate
board properties) being in an "okay" state. These cases are considered
bugs and need to be fixed in the drivers as and when identified.

[1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20201113211826.13087-3-nm@ti.com

The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.

In general, after a few rounds of discussions [1] there are few
options one could take when dealing with SoC dtsi and board dts

a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
   to prevent messy board files, when more boards are added per SoC, we
   optimize and disable commonly un-used nodes in board-common.dtsi
b. SoC dtsi disables all hardware dependent nodes by default and board
   dts files enable nodes based on a need basis.
c. Subjectively pick and choose which nodes we will disable by default
   in SoC dtsi and over the years we can optimize things and change
   default state depending on the need.

While there are pros and cons on each of these approaches, the right
thing to do will be to stick with device tree default standards and
work within those established rules. So, we choose to go with option
(a).

Lets cleanup defaults of am654 SoC dtsi before this gets more harder
to cleanup later on and new SoCs are added.

The dtb generated is identical with the patch and it is just cleanup to
ensure we have a clean usage model

NOTE: There is a known risk of omission that new board dts developers
might miss reviewing both the board schematics in addition to all the
DT nodes of the SoC when setting appropriate nodes status to disable
or reserved in the board dts. This can expose issues in drivers that
may not anticipate an incomplete node (example: missing appropriate
board properties) being in an "okay" state. These cases are considered
bugs and need to be fixed in the drivers as and when identified.

[1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20201113211826.13087-2-nm@ti.com

J7200 has a single instance of 8 channel ADC in MCU domain. Add DT node
for the same.
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20201029050950.4500-1-vigneshr@ti.com

Fix the node address to follow the device tree convention.

This fixes the dtc warning:
<stdout>: Warning (simple_bus_reg): /bus@100000/dss@04a00000: simple-bus
unit address format error, expected "4a00000"

Fixes: 76921f15 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
Fixes: fc539b90 ("arm64: dts: ti: am654: Add DSS node")
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://lore.kernel.org/r/20201104222519.12308-1-nm@ti.com

Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within both the MCU and MAIN domains for the
TI J721E EVM boards. These nodes are assigned to the respective rproc
device nodes as well. The first region will be used as the DMA pool for
the rproc device, and the second region will furnish the static carveout
regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The R5F processors do not have an MMU, and as such require the
exact memory used by the firmwares to be set-aside. The firmware images
do not require any RSC_CARVEOUT entries in their resource tables either
to allocate the memory for firmware memory segments.

Note that the R5F1 carveouts are needed only if the R5F cluster is running
in Split (non-LockStep) mode. The reserved memory nodes can be disabled
later on if there is no use-case defined to use the corresponding
remote processor.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-9-s-anna@ti.com

Add the required 'mboxes' property to all the R5F processors for the
TI J721E common processor board. The mailboxes and some shared memory
are required for running the Remote Processor Messaging (RPMsg) stack
between the host processor and each of the R5Fs. The nodes are therefore
added in the common k3-j721e-som-p0.dtsi file so that all of these can
be co-located.

The chosen sub-mailboxes match the values used in the current firmware
images. This can be changed, if needed, as per the system integration
needs after making appropriate changes on the firmware side as well.

Note that any R5F Core1 resources are needed and used only when that
R5F cluster is configured for Split-mode.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-8-s-anna@ti.com

The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
the two R5F cores are each added as child nodes to the corresponding
main cluster node. Both the clusters are configured to run in LockStep
mode by default, with the ATCMs enabled to allow the R5 cores to execute
code from DDR with boot-strapping code from ATCM. The inter-processor
communication between the main A72 cores and these processors is
achieved through shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if needed:
    MAIN R5FSS0 Core0: j7-main-r5f0_0-fw (both in LockStep and Split modes)
    MAIN R5FSS0 Core1: j7-main-r5f0_1-fw (needed only in Split mode)
    MAIN R5FSS1 Core0: j7-main-r5f1_0-fw (both in LockStep and Split modes)
    MAIN R5FSS1 Core1: j7-main-r5f1_1-fw (needed only in Split mode)
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-7-s-anna@ti.com

The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5F cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in LockStep mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if needed:
    MCU R5FSS0 Core0: j7-mcu-r5f0_0-fw (both in LockStep and Split modes)
    MCU R5FSS0 Core1: j7-mcu-r5f0_1-fw (needed only in Split mode)
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-6-s-anna@ti.com

Add a reserved memory node to reserve a portion of the DDR memory to be
used for performing inter-processor communication between all the MCU R5F
remote processors running RTOS on all the TI AM654 boards. This memory
shall be exercised only if the MCU R5FSS cluster is configured for Split
mode.  A single 1 MB of memory at 0xa2000000 is reserved for this purpose,
and this accounts for all the vrings and vring buffers between pair of
these R5F remote processors.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-5-s-anna@ti.com

The R5F processors do not have an MMU, and as such require the exact memory
used by the firmwares to be set-aside. Four carveout reserved memory nodes
have been added with two each (1 MB and 15 MB in size) used for each of the
MCU R5F remote processor devices on all the TI K3 AM65x boards. These nodes
are assigned to the respective rproc device nodes as well.

The current carveout addresses and sizes are defined statically for each
device. The first region will be used as the DMA pool for the rproc
device, and the second region will furnish the static carveout regions
for the firmware memory.

Note that the R5F1 carveouts are needed only if the corresponding R5F
cluster is running in Split (non-LockStep) mode. The corresponding
reserved memory nodes can be disabled later on if there is no use-case
defined to use the corresponding remote processor.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-4-s-anna@ti.com

Add the required 'mboxes' property to both the R5F processors on all the
TI K3 AM65x boards. The mailboxes and some shared memory are required
for running the Remote Processor Messaging (RPMsg) stack between the
host processor and each of the R5Fs. The chosen sub-mailboxes match the
values used in the current firmware images. This can be changed, if
needed, as per the system integration needs after making appropriate
changes on the firmware side as well.

Note that the R5F Core1 resources are needed and used only when the
R5F cluster is configured for Split-mode.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-3-s-anna@ti.com

The AM65x SoCs have a single dual-core Arm Cortex-R5F processor (R5FSS)
subsystem/cluster. This R5F cluster (MCU_R5FSS0) is present within the
MCU domain, and can be configured at boot time to be either run in a
LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in
Split-mode. This subsystem has 64 KB each Tightly-Coupled Memory (TCM)
internal memories for each core split between two banks - TCMA and TCMB
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5F clusters such as the absence of an ACP
port, presence of an additional TI-specific Region Address Translater
(RAT) module for translating 32-bit CPU addresses into larger system
bus addresses etc.

Add the DT node for this R5F cluster/subsystem, the two R5F cores are
added as child nodes to the main cluster node. The cluster is configured
to run in LockStep mode by default, with the ATCMs enabled to allow the
R5 cores to execute code from DDR with boot-strapping code from ATCM.
The inter-processor communication between the main A53 cores and these
processors is achieved through shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if needed:
    am65x-mcu-r5f0_0-fw (LockStep mode and for Core0 in Split mode)
    am65x-mcu-r5f0_1-fw (Core1 in Split mode)
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-2-s-anna@ti.com

DSS is IO coherent on AM65, so we should mark it as such with
'dma-coherent' property in the DT file.

Fixes: fc539b90 ("arm64: dts: ti: am654: Add DSS node")
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NNikhil Devshatwar <nikhil.nd@ti.com>
Cc: stable@vger.kernel.org # v5.8+
Link: https://lore.kernel.org/r/20201102134650.55321-1-tomi.valkeinen@ti.com

Remove obsolete "ti,dma-ring-reset-quirk" Ringacc DT property.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200829184139.15547-4-grygorii.strashko@ti.com

The board uses lane 3 of SERDES for USB. Set the mux
accordingly.

The USB controller and EVM supports super-speed for USB0
on the Type-C port. However, the SERDES has a limitation
that upto 2 protocols can be used at a time. The SERDES is
wired for PCIe, QSGMII and USB super-speed. It has been
chosen to use PCI2 and QSGMII as default. So restrict
USB0 to high-speed mode.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-7-rogerq@ti.com

First two lanes of SERDES is connected to PCIe, third lane is
connected to QSGMII and the last lane is connected to USB. However,
Cadence torrent SERDES doesn't support more than 2 protocols
at the same time. Configure it only for PCIe and QSGMII.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-6-rogerq@ti.com

j7200 has on USB controller instance. Add that.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-5-rogerq@ti.com

The USB controller can be connected to one of the 2 lanes
of SERDES0 using a MUX. Add a MUX controller node for that.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-4-rogerq@ti.com

The SERDES lane control mux registers are present in the
CTRLMMR space.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-3-rogerq@ti.com

The convention for node names is to use hyphens, not underscores.
dtschema for pca95xx expects GPIO hogs to end with 'hog' prefix.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200916155715.21009-7-krzk@kernel.org

Add support for the eMMC and SD card connected on the common
processor board

sdhci0 is connected to an eMMC while sdhci1 is connected to the
micro SD slot.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200924112644.11076-3-faiz_abbas@ti.com

Add support for MMC/SD controller nodes present on TI's j7200 SoCs.

There are two nodes:
        1. sdhci0 (8 bit bus width, 200 MHz, HS200, 200 MBps)
        2. sdhci1 (4 bit bus width, 50 MHz, HS, 25 MBps)
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200924112644.11076-2-faiz_abbas@ti.com

J7200 SoM has a HyperFlash connected to HyperBus memory controller. But
HyperBus is muxed with OSPI, therefore keep HyperBus node disabled.
Bootloader will detect the mux and enable the node as required.
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200923163150.16973-3-vigneshr@ti.com

J7200 has a Flash SubSystem that has one OSPI and one HyperBus.. Add
DT nodes for HyperBus controller for now.
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200923163150.16973-2-vigneshr@ti.com

Add DT nodes for I2C GPIO expanders on main_i2c0 and main_i2c1 and
also add the pinmux corresponding to these I2C instances.
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Reviewed-by: NFaiz Abbas <faiz_abbas@ti.com>
Link: https://lore.kernel.org/r/20200923155400.13757-3-vigneshr@ti.com

J7200 has 7 I2Cs in main domain, 2 I2Cs in MCU and 1 in wakeup domain.
Add DT nodes for the same.
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Reviewed-by: NFaiz Abbas <faiz_abbas@ti.com>
Link: https://lore.kernel.org/r/20200923155400.13757-2-vigneshr@ti.com

The TI J7200 EVM base board has TI DP83867 PHY connected to external CPSW
NUSS Port 1 in rgmii-rxid mode.

Hence, add pinmux and Ethernet PHY configuration for TI J7200 SoC MCU
Gigabit Ethernet two ports Switch subsystem (CPSW NUSS).
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSuman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200923220938.30788-5-grygorii.strashko@ti.com

Add DT node for The TI J7200 MCU SoC Gigabit Ethernet two ports Switch
subsystem (MCU CPSW NUSS).
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSuman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200923220938.30788-4-grygorii.strashko@ti.com