AM62 SoC devices have a single core R5F processor in wakeup domain.
The R5F processor in wakeup domain is used as a device manager
for the SoC.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Daniel Schultz <d.schultz@phytec.de>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250502220325.3230653-3-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add another entry in the wkup_conf for the syscon node, and then use
that for the syscon in opp-table.
Marking entire wkup_conf as "syscon", "simple-mfd" is wrong and needs to
be addressed similar to how other child-nodes in wkup_conf are implemented
in the same file.
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20241104063707.3604302-1-d-gole@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>
Exposing the entire CTRL_MMR space to syscon is not a good idea.
Add sub-nodes for USB0_PHY_CTRL and USB1_PHY_CTRL and use them
in the USB0/USB1 nodes.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240412-for-v6-10-am62-usb-typec-dt-v7-1-93b827adf97e@kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
The devices in the wkup domain are capable of waking up the system from
suspend. We can configure the wkup domain devices in a generic way using
the ti-sysc interconnect target module driver like we have done with the
earlier TI SoCs.
As ti-sysc manages the SYSCONFIG related registers independent of the
child hardware device, the wake-up configuration is also set even if
wkup_uart0 is reserved by sysfw.
The wkup_uart0 device has interconnect target module register mapping like
dra7 wkup uart. There is a 1 MB interconnect target range with one uart IP
block in the target module. The power domain and clock affects the whole
interconnect target module.
Note we change the functional clock name to follow the ti-sysc binding
and use "fck" instead of "fclk".
Also note that we need to disable the target module reset as noted by
Markus. Otherwise the sysfw using wkup_uart0 can get confused on some
devices leading to boot time issues such as mbox timeouts.
Tested-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20240213112510.6334-1-tony@atomide.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Modify license to include dual licensing as GPL-2.0-only OR MIT
license for SoC and TI evm device tree files. This allows for Linux
kernel device tree to be used in other Operating System ecosystems
such as Zephyr or FreeBSD.
While at this, update the GPL-2.0 to be GPL-2.0-only to be in sync
with latest SPDX conventions (GPL-2.0 is deprecated).
While at this, update the TI copyright year to sync with current year
to indicate license change (and add it at least for one file which was
missing TI copyright).
Cc: Guillaume La Roque <glaroque@baylibre.com>
Cc: Julien Panis <jpanis@baylibre.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Roger Quadros <rogerq@kernel.org>
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Cc: Sarah Walker <sarah.walker@imgtec.com>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Guillaume La Roque <glaroque@baylibre.com>
Acked-by: Julien Panis <jpanis@baylibre.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Ronald Wahl <ronald.wahl@raritan.com>
Acked-by: Sarah Walker <sarah.walker@imgtec.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20240122145539.194512-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.
On TI K3 AM625 SoC, only secure_proxy_sa3 and esm nodes are
exclusively used by R5 bootloader, rest of the dts nodes with bootph-* are
used by later boot stages also.
Add bootph-all for all other nodes that are used in the bootloader on
K3 AM625 SoC, and bootph-pre-ram is not needed specifically for any
other node in kernel dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911162535.1044560-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The am62x supports a single Voltage and Thermal Management (VTM) module
located in the wakeup domain with two associated temperature monitors
located in hot spots of the die.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-3-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Introduce digital RTC node in wakeup domain. Even though this has
no specific battery backup supply, this on-chip RTC is used in
cost-optimized board designs as a wakeup source.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230320165123.80561-2-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Hex numbers in addresses and sizes should be rather eight digits, not
nine. Drop leading zeros. No functional change (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20221115105044.95225-1-krzysztof.kozlowski@linaro.org
I2C nodes defined in the top-level AM62x SoC dtsi files are incomplete
and will not be functional unless they are extended with pinmux
information.
As the pinmux is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the I2C nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20221018211533.21335-3-afd@ti.com
UART nodes defined in the top-level AM62x SoC dtsi files are incomplete
and will not be functional unless they are extended with pinmux
information.
As the pinmux is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the UART nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20221018211533.21335-2-afd@ti.com
This add bare minimum DT for AM62 describing ARM compute clusters, Main,
MCU and Wakeup domain and interconnects, UARTs and I2Cs to enable
booting using ramdisk.
Hierarchy of dts files:
am62.dtsi:
base SoC skeleton which is common across am62xx family of SoCs,
includes am62-main.dtsi, am62-mcu.dtsi and am62-wakeup.dtsi
representing 3 domains and peripherals in each of these domain
am625.dtsi:
describes CPU cluster (Quad A53s). Since, am625 is a current superset
device with all peripherals, am625.dtsi includes am62.dtsi completing
SoC definition.
Individual EVMs using this SoC will just need to include am625.dtsi
thus making things easier for Board and SOM Vendors.
Future derivative SoCs will have their own am62{1-9}{1-9}.dtsi
overriding cluster / peripheral definitions with their own compatibles.
More details about the SoCs can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7
Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220225120239.1303821-5-vigneshr@ti.com
