Fix the following warnings when compiling dtbs with W=1:
../arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi:343.10-353.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/tps6598x@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
../arch/arm64/boot/dts/ti/k3-am62-main.dtsi:633.22-643.5: Warning (graph_child_address): /bus@f0000/dwc3-usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
Cc: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240626101520.1782320-3-d-gole@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Fix the following warnings that are thrown when building dtbs with W=1:
../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:367.10-376.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/usb-power-controller@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
../arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi:647.22-657.5: Warning (graph_child_address): /bus@f0000/usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
also defined at ../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:517.7-528.3
Cc: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240626101520.1782320-2-d-gole@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM67A/J722S/TDA4AEN platform is a derivative of AM62P platform
and we have no single 1:1 relation regarding index of GPIO and pin
controller. The GPIOs and pin controller registers have mapping and
holes in the map. These have been extracted from the J722S data
sheet. The MCU mapping is carried forward as is with J722S, however the
main GPIO block has differences that needs to be accounted for.
Mux mode input is selected as it is bi-directional. In case a specific
pull type or a specific pin level drive setting is desired, the board
device tree files will have to explicitly mux those pins for the GPIO
with the desired setting.
Ref: J722S Data sheet https://www.ti.com/lit/gpn/tda4aen-q1
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
On the AM62P platform we have no single 1:1 relation regarding index
of GPIO and pin controller. The GPIOs and pin controller registers
have mapping and holes in the map. These have been extracted from the
AM62P data sheet.
MCU pinctrl definition is shared as it is common between AM62P and
J722S, but that is not the case for main domain.
Ref: AM62P Data sheet https://www.ti.com/lit/gpn/am62p
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Introduce a GPIO mux mode macro for easier readability. All K3 devices
use mux mode 7 to switch to GPIO mux and this allows the gpio-ranges to
be defined for pinctrl-single clearly.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The WKUP system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-8-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The WKUP system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-7-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-6-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-5-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-4-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-3-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The phyCORE-AM62Ax [1] is a SoM (System on Module) featuring TI's AM62Ax SoC.
It can be used in combination with different carrier boards.
This module can come with different sizes and models for
DDR, eMMC, SPI NOR Flash and various SoCs from the AM62Ax family.
A development Kit, called phyBOARD-Lyra [2] is used as a carrier board
reference design with a mapper board being used to allow the phyCORE-AM62Ax
to fit the phyBOARD-Lyra.
Supported features:
* Debug UART
* SPI NOR Flash
* eMMC
* 2x Ethernet
* Micro SD card
* I2C EEPROM
* I2C RTC
* GPIO Expander
* LEDs
* USB
* HDMI
* USB-C
* Audio
For more details, see:
[1] Product page SoM: https://www.phytec.com/product/phycore-am62a
[2] Product page CB: https://www.phytec.com/product/phyboard-am62a
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240626155244.3311436-4-ggiordano@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The audio support on J784S4-EVM is using PCM3168A[0] codec
connected to McASP0 serializers.
- Add the nodes for sound-card, audio codec, MAIN_I2C3 and
McASP0.
- Add pinmux for I2C3, McASP0 and AUDIO_EXT_REFCLK1.
- Add necessary GPIO hogs to route the MAIN_I2C3 lines and
McASP serializer.
- Add idle-state as 1 in mux1 to route McASP clock signals.
[0]: <https://www.ti.com/lit/gpn/pcm3168a>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20240626101645.36764-4-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The NAND expansion card (PROC143E1) connects over the User/MCU/PRU
Expansion port on the am62-lp-sk EVM.
The following pins are shared between McASP1 and GPMC-NAND so
both cannot work simultaneously.
Pin name McASP1 function GPMC function
======== =============== =============
J17 MCASP1_AXR0 GPMC0_WEN
P21 MCASP1_AFSX GPMC0_WAIT0
K17 MCASP1_ACLKX GPMC0_BE0N_CLE
K20 MCASP1_AXR2 GPMC0_ADVN_ALE
The factory default sets the pins for McASP1 use. (i.e.
Resistor Array RA1 installed, RA4 not installed).
For NAND use, RA1 has to be removed and RA4 must be
installed.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240622-am62lp-sk-nand-v1-2-caee496eaf42@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The audio support on J722S-EVM is using TLV320AIC3106[0] codec
connected to McASP1 serializers.
- Add the nodes for sound-card, audio codec and McASP1.
- Add hog for TRC_MUX_SEL to select between McASP and TRACE signals
- Add hogs for GPIO_AUD_RSTn and MCASP1_FET_SEL which is used to
switch between HDMI audio and codec audio.
- Add pinmux for MCASP1 and AUDIO_EXT_REFCLK1.
[0]: <https://www.ti.com/lit/gpn/TLV320AIC3106>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20240625113301.217369-3-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to change from the default OSPI NOR to QSPI NOR
for all am6xx-phycore-som boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an ospi nor, but if qspi nor is populated, the EEPROM will
indicate that change and we can use this overlay to cleanly change to
qspi nor.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240621233143.2077941-1-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
I2C1 controller controls io-expander which provides power to voltage
regulator vdd_mmc1 for MMC SD using a gpio line.
Add bootph-all to the pinmux node for this instance, as this is used during
SPL stage too by the bootloader while using SD boot mode as without this
the SD boot mode fails with below error when using this device-tree in
u-boot:
"Timed out in wait_for_event: status=0000
Check if pads/pull-ups of bus are properly configured
Timed out in wait_for_event: status=0000
Check if pads/pull-ups of bus are properly configured
"
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20240614123532.203983-1-devarsht@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Certain device-tree node properties of shared device-tree nodes are
different between the AM62P and J722S SoCs. To avoid overriding the
properties and to avoid redefining the nodes in the k3-{soc}-main.dtsi
having such SoC specific properties, move the properties to the SoC
specific k3-{soc}-main.dtsi files.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-9-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable PCIe0 instance of PCIe in Root Complex mode of operation with Lane 0
of the SERDES1 instance of SERDES. Also enable USB0 instance of USB to
interface with the Type-C port via the USB hub, by configuring the pin P05
of the GPIO expander on the EVM. Enable USB1 instance of USB in SuperSpeed
mode of operation with Lane 0 of the SERDES0 instance of SERDES.
Co-developed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-8-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J722S SoC has two instances of SERDES namely SERDES0 and SERDES1 and one
instance of PCIe namely PCIe0. Both SERDES0 and SERDES1 are single lane
SERDES. The PCIe0 instance of PCIe is a Gen3 single lane PCIe controller.
Since SERDES and PCIe are not present on AM62P SoC, add the device-tree
nodes corresponding to them in the J722S SoC specific "k3-j722s-main.dtsi"
file.
Co-developed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-7-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The SERDES0 and SERDES1 instances of SERDES on J722S are single lane
SERDES which are individually muxed across different peripherals.
LANE0 of SERDES0 is muxed between USB and CPSW while LANE0 of SERDES1 is
muxed between PCIe and CPSW.
Define the lane-muxing macros to be used as the idle state values.
Co-developed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-6-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Update "k3-j722s.dtsi" to include "k3-am62p-j722s-common-{}".dtsi files in
order to reuse the nodes shared with AM62P. Also include the J722S specific
"k3-j722s-main.dtsi".
Since the J7 family of SoCs has the k3-{soc}.dtsi file organized as:
k3-{soc}.dtsi = CPU + Cache + CBASS-Ranges + "Peripheral-Includes"
switch the "k3-j722s.dtsi" file to the same convention.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-5-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The USB1 instance of USB controller on AM62P is different from the USB1
instance of USB controller on J722S. Thus, move the USB1 instance from
the shared "k3-am62p-j722s-common-main.dtsi" file to the AM62p specific
"k3-am62p-main.dtsi" file. Include "k3-am62p-main.dtsi" in "k3-am62p.dtsi".
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-3-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM62P and J722S SoCs share most of the peripherals. With the aim of
reusing the existing k3-am62p-{mcu,main,thermal,wakeup}.dtsi files for
J722S SoC, rename them to indicate that they are shared with the J722S SoC.
The peripherals that are not shared will be moved in the upcoming patches
to the respective k3-{soc}-{mcu,main,wakeup}.dtsi files without "common" in
the filename, emphasizing that they are not shared.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-2-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The NAND expansion card plugs in over the HSE (High Speed Expansion)
connector. Add support for it.
We add the ranges property to the GPMC node instead of the NAND
overlay file to prevent below warnings.
/fragment@3/__overlay__: Relying on default #address-cells value
/fragment@3/__overlay__: Relying on default #size-cells value
As GPMC is dedicated for NAND use on this board, it should be OK.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240614-am642-evm-nand-v5-1-acf760896239@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to disable the spi nor for all am6xx-phycore-som
boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an ospi nor, but if no nor is populated, the EEPROM will indicate
that change and we can use this overlay to cleanly disable the
spi nor.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-5-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to disable the rtc for all am6xx-phycore-som boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an rtc, but if no rtc is populated, the EEPROM will indicate that
change and we can use this overlay to cleanly disable the rtc.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-4-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to disable the eth phy for all am6xx-phycore-som
boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an ethernet phy, but if no ethernet phy is populated, the EEPROM
will indicate that change and we can use this overlay to cleanly
disable the ethernet phy.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-3-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E common processor board can be interfaced with the infotainment
expansion board[0] to enable the following audio/video interfaces in
addition to the peripherals provided by the common processor board:
- Two Audio codecs each with three Stereo Inputs and four Stereo Outputs
- Audio input over FPD Link III
- Digital Audio Interface TX/RX
- HDMI/FPD LINK III Display out
- LI/OV Camera input
Add support for TFP410 HDMI bridge located on the Infotainment Expansion
Board (connected to J46 & J51).
Add a HDMI connector node and connect the endpoints as below:
DSS => TFP410 bridge => HDMI connector
Also add the pinmux data and board muxes for DPI.
Rest of the peripherals are not added as of now.
[0]: <https://www.ti.com/lit/ug/spruit0a/spruit0a.pdf>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[j-choudhary@ti.com: minor cleanup]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Link: https://lore.kernel.org/r/20240613093706.480700-1-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
