| Age | Commit message (Collapse) | Author |
|---|
|
SCMI base protocol device does not have a device tree, it should use and
need to use the agent base channel.
For scmi_base.[x], there is no real device tree node for it. ofnode_null() is
assigned as the device tree node for scmi base protocol device:
commit 7eb4eb541c14 ("firmware: scmi: install base protocol to SCMI agent")
However with recent update in commit 0535e46d55d7
("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c"),
SPL panic in fdt_check_node_offset_()->fdt_next_tag(), because offset is -1
and SPL_OF_LIBFDT_ASSUME_MASK is 0xFF.
So add a check in x_get_channel() to validate the protocol devices'
ofnode.
Reported-by: Ye Li <ye.li@nxp.com>
Closes: https://lore.kernel.org/u-boot/939a9696-27fa-45a1-b428-feffe21ac6d5@oss.nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The sandbox scmi clock protocol use version 3.0, so need to use
scmi_clk_state_in_v2.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c8c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).
This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
SOC can boot from different boot medias and also different offsets that's
why by default show multiboot value to be aware which image system is
booting out of. It is especially useful for systems with A/B update
enabled.
Also limit zynqmp_pm_get_pmc_multi_boot_reg() usage only for Versal and
Versal Gen 2.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/fd7564ce2f51d965c273e939e98de01beb92e6f5.1764232124.git.michal.simek@amd.com
|
|
Versal Gen 2 is using different SMC format that's why firmware and clock
drivers needs to be align with it.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/16bdee56fd75113c6d531bae7a8a34900b10280d.1762788250.git.michal.simek@amd.com
|
|
- Fix temp memory leak
- Free memory during error handling
Signed-off-by: Francois Berder <fberder@outlook.fr>
|
|
SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.
Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.
No functional change for the SCMI drivers users of the related enable and
disable clock operations.
[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
Support both old < 2.1 and new >= 2.1 protocol versions.
Update commit message based on Linux one]
Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
MMU region cache behavior configuration for SCMI/SMT mailboxes is
platform specific. Even on ARM systems, the mailbox memory may not
even be located in any cacheable MMU region and may instead reside
in some SRAM. Remove this non-generic cache behavior configuration
code from generic code path.
It is unlikely that any platform is affected by this change if it
did configure its MMU regions correctly on start up. Platforms
which might be affected are i.MX94/95 and STM32MP.
Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device")
Fixes: 2a3f161c8b16 ("scmi: correctly configure MMU for SCMI buffer")
Fixes: b2ae10970d40 ("firmware: scmi: use PAGE_SIZE alignment for ARM64")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Alice Guo <alice.guo@nxp.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
This protocol allows an agent to start, stop a CPU or set reset vector.
It is used to manage auxiliary CPUs in an LM (e.g. additional cores in an
AP cluster).
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
|
|
Add Logical Machine Management(LMM) protocol which is intended for boot,
shutdown, and reset of other logical machines (LM). It is usually used to
allow one LM to manager another used as an offload or accelerator engine.
Following Linux Kernel, created a separate folder for holding vendor
protocol drivers.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
|
|
Preparing to add i.MX LMM and CPU protocol driver, support probe SCMI
vendor ID 0x80(i.MX SCMI LMM ID) and 0x82(i.MX SCMI CPU ID). And use
Kconfig option to support conditional compilation.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
|
|
Add conditional compilation for SCMI protocol support in scmi_get_protocol()
and scmi_add_protocol() based on corresponding Kconfig options. This ensures
that only the enabled protocols are compiled and accessed, and reducing binary
size.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
|
|
The pointer resp is declared but never assigned a value but is then
dereferenced. Fix this by assigning the pointer to the message buffer.
This issue was found by Smatch.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>
|
|
In ti_sci_get_response the check for message sequence will return ret
on a fail but ret will be 0 at that point. Instead return -EINVAL.
Also change dev_dbg call to dev_err to be consistent with other error
detection code in the same function.
This issue was found by Smatch.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>
|
|
temp is assigned the pointer returned by malloc which is used without a
NULL check and then never freed. Add a NULL check and ensure temp is
freed on all return paths.
This issue was found by Smatch.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
AMD/Xilinx/FPGA changes for v2026.01-rc1 v2
zynqmp:
- DT updates
- Enable new commands
mbv:
- Simplify defconfigs
clk:
- Separate legacy handler and use SMC handler
misc:
- Tighten TTC Kconfig dependency
net:
- Add 10GBE support to Gem
pwm:
- cadence-ttc: Fix array sizes
fwu:
- Add platform hook support
spi:
- Remove undocumented cdns,is-dma property
video:
- Fix DPSUB RGB handling
|
|
Per devicetree bindings:
arm,max-rx-timeout-ms indicates an optional time value, expressed in
milliseconds, representing the transport maximum timeout value for the
receive channel. The value should be a non-zero value if set.
Support this property if platform set it to a non-default value. This
property is a per SCMI property, so all channels share same value.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Following Linux Kernel drivers/firmware/arm_scmi/transports/mailbox.c to
set the default timeout to 30ms.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
For ARMv7, the alignment could be SECTION size. But for ARM64, use
PAGE_SIZE.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
In SCMI spec 3.2, there is an update:
Add IN_USE error code for usage with Pin control protocol
So add the error decoding for IN_USE.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
"Buffer too small" is too vague, dump more info to make it easier to
debug issues.
Change dev_dbg to dev_err when buffer is too small.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
It is not good practice to directly use "hdr->x" to read/write the hdr,
because the SCMI buffer may not mapped as normal memory. Following Linux
Kernel, using ioread32/iowrite32/memcpy_[from,to]io for smt header read,
write.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Typo: 'to' -> 'too'
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Currently xilinx_pm_request API supports four u32 payloads. However the
legacy SMC format supports five u32 request payloads and extended SMC
format supports six u32 request payloads. Add support for the same in
xilinx_pm_request API. Also add two dummy arguments to all the callers
of xilinx_pm_request.
The TF-A always fills seven u32 return payload so add support
for the same in xilinx_pm_request API.
Signed-off-by: Naman Trivedi <naman.trivedimanojbhai@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Acked-by: Senthil Nathan Thangaraj <senthilnathan.thangaraj@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/5ae6b560741f3ca8b89059c4ebb87acf75b4718e.1756388537.git.michal.simek@amd.com
|
|
CONFIG_IS_ENABLED macro is covering CONFIG_POWER_DOMAIN or
CONFIG_SPL_POWER_DOMAIN Kconfig symbols based on build target which
simplify logic around binding power domain driver.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/c75627e92eeaffedf0f7e682edd4f6f39f0b5706.1752826352.git.michal.simek@amd.com
|
|
Separate code to own function to be able to add new enhancement format.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/cf99fe1af82bc004de3e313d4018464f4504f380.1750858165.git.michal.simek@amd.com
|
|
The ZYNQMP_FIRMWARE code cannot build without platform specific headers
being available. Express that requirement in Kconfig as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
Link: https://lore.kernel.org/r/20250702010410.18828-1-trini@konsulko.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Add a function to retrieve information of the DM firmware's ABI versions,
RM/PM HAL, firmware version, etc using TI_SCI protocol.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
Add a new function to query the capabilities of the DM firmware, using
TI SCI protocol to retrieve a 64-bit firmware capability, where each bit
represents a specific capability supported by the firmware.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
Introduce response and request structs to receive and request
information regarding DM version, etc from TI SCI.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
Introduce response and request structs for receiving information
regarding FW/SOC capability from DM. The received capability can
further be used to call certain API's based on the feature supoorted
by the DM firmware.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
On K3 devices two drivers ti_sci and ti_sci_dm are supporting firmware
functions. At run time one of driver is used.
Driver ti_sci already initializing head for dev_list in its probe
function, but it was missed in ti_sci_dm driver.
So add head list init support for ti_sci_dm driver.
While at this, move init of list before usages in both functions.
Fixes: 5d5a699855a7("firmware: ti_sci: Add support for Resoure Management at R5 SPL stage")
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
|
|
@protocols is an array of protocol identifiers that are implemented,
excluding the Base protocol. Four protocol identifiers are packed into
each array element. The number of elements of @protocols is specified by
callee-side.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
|
|
This patch is used to add SCMI clock control permissions to sandbox for
testing.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
|
|
This patch adds SCMI pin control protocol support to make the pin
controller driver based on SCMI, such as
drivers/pinctrl/nxp/pinctrl-imx-scmi.c, can be bound to the SCMI agent
device whose protocol id is 0x19.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
|
|
If there is a SoC specific SCMI protocol driver, using
scmi_proto_driver_get() function can avoid to add SoC specific code to
scmi_agent-uclass.c.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
|
|
linker-genetated array
U_BOOT_SCMI_PROTO_DRIVER macro is used to add a SCMI protocol driver to
scmi_proto_driver list. scmi_proto_driver_get() function can be used to
match a SCMI protocol id and its driver.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
|
|
It is very surprising that such an uclass, specifically designed to
handle resources that may be shared by different devices, is not keeping
the count of the number of times a power domain has been
enabled/disabled to avoid shutting it down unexpectedly or disabling it
several times.
Doing this causes troubles on eg. i.MX8MP because disabling power
domains can be done in recursive loops were the same power domain
disabled up to 4 times in a row. PGCs seem to have tight FSM internal
timings to respect and it is easy to produce a race condition that puts
the power domains in an unstable state, leading to ADB400 errors and
later crashes in Linux.
Some drivers implement their own mechanism for that, but it is probably
best to add this feature in the uclass and share the common code across
drivers. In order to avoid breaking existing drivers, refcounting is
only enabled if the number of subdomains a device node supports is
explicitly set in the probe function. ->xlate() callbacks will return
the power domain ID which is then being used as the array index to reach
the correct refcounter.
As we do not want to break existing users while stile getting
interesting error codes, the implementation is split between:
- a low-level helper reporting error codes if the requested transition
could not be operated,
- a higher-level helper ignoring the "non error" codes, like EALREADY and
EBUSY.
CI tests using power domains are slightly updated to make sure the count
of on/off calls is even and the results match what we *now* expect. They
are also extended to test the low-level functions.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The current code attempts to bind scmi_voltage_domain to regulator subnode
of the SCMI protocol node, so scmi_voltage_domain can then bind regulators
directly to subnodes of its node. This kind of behavior should not be in
core code, move it into scmi_voltage_domain driver code. Let the driver
descend into regulator node and bind regulators to its subnodes.
Fixes: 1f213ee4dbf2 ("firmware: scmi: voltage regulator")
Signed-off-by: Marek Vasut <marex@denx.de>
[Alice Guo: Fix scmi_regulator_bind]
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Unfortunately this change breaks boot on K3 platform.
U-Boot will hang after:
U-Boot SPL 2025.04-01050-ga40fc5afaec0 (Apr 14 2025 - 07:31:32 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.7--v09.02.07 (Kool Koala)')
This reverts commit 197376fbf300e92afa0a1583815d9c9eb52d613a as
suggested in [1].
[1] https://lists.denx.de/pipermail/u-boot/2025-April/587032.html
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Update the firmware driver UFS APIs zynqmp_pm_ufs_* to directly
read/write to the pmc_iou_slcr and efuse_cache registers. Replace
these raw reads/writes with the xilinx_pm_request() API with the
correct arguments once the PM related changes are done.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/ee2d1ad2e07e96f1948ab6ffe8f3c50a3b8f9be9.1742462001.git.michal.simek@amd.com
|
|
Added extended support for retrieving the PMC muti boot mode
register via the firmware interface, which is preferred when
U-Boot runs in EL2 and cannot directly access PMC registers
via raw reads. Ideally, all secure registers should be accessed
via xilinx_pm_request(). Introduced the secure
zynqmp_pm_get_pmc_multi_boot_reg() call, which uses
xilinx_pm_request() to read the PMC multi boot mode register.
BootROM increments the MultiBoot register (PMC_MULTI_BOOT) read
address offset by 32 KB and retries. For SD and eMMC boot modes,
it can search up to 8191 FAT files for the identification string.
A 13-bit mask (0x1FFF) is applied to PMC_MULTI_BOOT_MASK to obtain
the correct values in BootROM.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250305134845.3182193-1-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Added extended support for retrieving the boot mode register
via the firmware interface, which is preferred when U-Boot
runs in EL2 and cannot directly access CRP registers via raw
reads. Ideally, all secure registers should be accessed via
xilinx_pm_request(). Introduced the secure zynqmp_pm_get_bootmode_reg()
call, which uses xilinx_pm_request() to read the boot mode register.
When CONFIG_ZYNQMP_FIRMWARE is enabled, the secure
zynqmp_pm_get_bootmode_reg() call is used; otherwise,
direct raw reads are performed in the case of mini U-Boot.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250219115301.3661036-1-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
When FIT image with multiple dtbs are involved for R5 boot process,
R5 SPL starts off with the first instance of dtb to probe the
eeprom, then once we have identified the type of board, invocation
of setup_multi_dtb_fit will replace the gd->fdt_blob with the proper
board dtb match. However, when we do this, two things happen:
a) Prior to the invocation of setup_multi_dtb_fit, as part of the eeprom
discovery process, i2c controller device is already probed and marked
as exclusive with the match of the very first tisci match (from the
original boot dtb). This list is stored in the info->dev_list of the
first probe.
b) When the second dtb is loaded, tisci is probed again (since this is a
new node) and the new info->dev_list is empty.
At this stage, the exclusive devices such as i2c instances used to
probe the board information is left in the old info->dev_list that is
no longer used actively by the system using the replaced dtb.
As a result of this, the cleanup we intend to do with
ti_sci_cmd_release_exclusive_devices is no longer complete and
leaves the instances such as i2c for eeprom marked used as we scan just
the new info->dev_list.
This creates a problem when Device Manager(DM) firmware starts up later
on in the boot process and identifies that this instance of i2c is
already marked active, so it assumes this can no longer be controlled
by software and is marked internally as reserved and HLOS can no
longer control these instances. This defeated the purpose of
ti_sci_cmd_release_exclusive_devices.
NOTE: This scheme works just fine if the FIT has just a single dtb as
the info->dev_list is upto date.
To fix this, let us make ti_sci_cmd_release_exclusive_devices scan the
all registrations of tisci instances and cleanup all exclusive devices
that have ever been registered.
As part of this, change the prototype of release_exclusive_devices to
drop the handle since that has no further meaning now.
Though this issue was identified on AM64-sk, this can be present in
other builds which use multi-fit-dtb for R5 SPL startup.
Fixes: 9566b777ae0a ("firmware: ti_sci: Add a command for releasing all exclusive devices")
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
|
|
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
i.MX95 System Manager uses interrupt driven communication which requires
the caller to set Bit[0] of channel flags to 1. When transmission
completes and the previous general purpose interrupt has been processed
by the other core, i.MX95 System Manager will set General Purpose
Interrupt Control Register (GCR). U-Boot polls General-purpose Status
(GSR) to check if the operation is finished.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
It is very surprising that such an uclass, specifically designed to
handle resources that may be shared by different devices, is not keeping
the count of the number of times a power domain has been
enabled/disabled to avoid shutting it down unexpectedly or disabling it
several times.
Doing this causes troubles on eg. i.MX8MP because disabling power
domains can be done in recursive loops were the same power domain
disabled up to 4 times in a row. PGCs seem to have tight FSM internal
timings to respect and it is easy to produce a race condition that puts
the power domains in an unstable state, leading to ADB400 errors and
later crashes in Linux.
CI tests using power domains are slightly updated to make sure the count
of on/off calls is even and the results match what we *now* expect.
As we do not want to break existing users while stile getting
interesting error codes, the implementation is split between:
- a low-level helper reporting error codes if the requested transition
could not be operated,
- a higher-level helper ignoring the "non error" codes, like EALREADY and
EBUSY.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Currently in j721e_init.c we check which firewalls to remove using
the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this
as J721e and J7200 have different IP and firewalls but use the same
SoC definition (SOC_K3_J721E) even though they are different SoCs.
The idea was they would be similar enough that they both could use
the same SoC config to help with common code sharing. Board checks
would then be used differentiate.
This has grown far too messy to maintain any more, especially now
that there is more than one board using J721e (EVM, SK, Beagle AI64).
As differentiation is done based on board, every one of these boards
would have to have checks added for them. Instead let's split J7200
support out from J721e like how normal new SoC support is done.
This patch touches several subsystems and could not be split much better
as when we add SOC_K3_J7200 we want to make use of it in all spots that
once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when
building for J7200 boards.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently the driver relies on bootph flag to probe it during PRE_RELOC
stage but with the upcoming cleanup of v6.13, we don't have the bootph
property in the parent nodes anymore and ti_sci driver being one of the
parent nodes required during SPL stage would end up hampering the probe
model [0].
Add DM_FLAG_PRE_RELOC to ti_sci driver for mitigating this issue.
[0]: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/21
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
|
