| Age | Commit message (Collapse) | Author |
|---|
|
The sysreset TI-SCI API is available with TI-SCI always, there is no need
for a DT node to describe the availability of this. If the sysreset driver
is available then bind it during ti-sci probe.
Remove the unneeded device tree matching.
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
According to PSCI specification DEN0022F, PSCI_FEATURES is used to check
whether the SMCCC is implemented by discovering SMCCC_VERSION.
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
|
|
Include the static DMA channel data for ti_sci
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Add support for DMA in J784S4 SoC.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
|
|
Add a comment to explain the code under is_secure condition of
ti_sci_do_xfer. This will help avoid confusion amongst people who may in
future touch upon this code.
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
|
|
The ti_sci driver in U-Boot has support for secure_msg as part of it's
do_xfer function. This let's U-boot send secure messages during boot up.
The protocol to send such secure messages is described as part of the
struct ti_sci_secure_msg_hdr. As part of this, there are 2 fields for
checksum and reserved that occupy the first 4 bytes of any secure
message. This is called as the secure_hdr.
As of now, the secure_hdr needs to be 0 init-ed before sending secure
messages. However the existing code was never putting the zero-inited vars
into the secure_buf, leading to possibility of the first 4 bytes of
secure_buf being possibly garbage.
Fix this by initialising the secure_hdr itself to the secure_buf
location, thus when we make secure_hdr members 0, it automatically ensures
the first 4 bytes of secure_buf are 0.
Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control Interface (TI SCI)")
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
|
|
As of now only one mailbox agent is supported by mailbox driver.
On zynqmp platform there are about 7 mailbox agents which can communicate
over same IPI channel to U-Boot. This patch series introduces new
"zynqmp_ipi_dest" driver which adds one to multi-channel mailbox
support.
Following format in device-tree is expected as per latest bindings:
zynqmp-ipi {
compatible = "xlnx,zynqmp-ipi-mailbox";
mbox_1: mailbox@1 {
/* New compatible for child node */
compatible = "xlnx,zynqmp-ipi-dest-mailbox";
...
};
...
mbox_n: mailbox@n {
compatible = "xlnx,zynqmp-ipi-dest-mailbox";
...
}
};
Then mailbox client uses child mailbox node as following:
ipi-dest-1 {
...
mboxes = <mbox_1 0>, <mbox_1 1>;
mbox-names = "tx", "rx";
...
};
New "zynqmp_ipi_dest" driver is for devices with
"xlnx,zynqmp-ipi-dest-mailbox" compatible string. This driver will take care
of mailbox send recv ops and it replaces previous "zynqmp_ipi" driver.
Now "zynqmp_ipi" driver simply binds each child device with "zynqmp_ipi_dest"
driver.
However, its important to maintain backward comaptibility with previous
bindings where child node does not have compatible string. In such case, new
driver isn't probed by U-Boot during boot and system fails to boot. To
resolve this issue firmware-zynqmp.c driver probes all the IPI parent node
driver which binds each child node device with "zynqmp_ipi_dest" driver.
This makes sure corresponding child driver will be
probed when requested using mbox_get_by_name or mbox_get_by_idx
framework calls.
This way multiple mailbox agents are supported in device-tree without breaking
previous binding support.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20231204215620.63334-4-tanmay.shah@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
This change will be useful when we manually test SCMI on sandbox
by enabling/disabling a specific SCMI protocol.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Replace instances of http://www.ti.com with https://www.ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
A power domain id on sandbox should be in the range from zero to
ARRAY_SIZE(scmi_pwdom) - 1. Correct the validity check logic.
Addresses-Coverity-ID: 467401 ("Out-of-bounds write")
Addresses-Coverity-ID: 467405 ("Out-of-bounds read")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
Unhandled error coming from xilinx_pm_request() but return
value is not read back that's why getting sparse warning
as below:
warning: variable 'ret' set but not used [-Wunused-but-set-variable].
In case of error return the "ret" value.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20231011025647.17200-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
address the CID 464361 Control flow issues [1]
[1]: https://lore.kernel.org/all/20230821210927.GL3953269@bill-the-cat/
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Cc: Tom Rini <trini@konsulko.com>
|
|
SCMI power domain management protocol is supported on sandbox
for test purpose. Add fake agent interfaces and associated
power domain devices.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add power domain driver based on SCMI power domain management protocol.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
In this patch, added are helper functions to directly manipulate
SCMI power domain management protocol. DM compliant power domain
driver will be implemented on top of those interfaces in a succeeding
patch.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
The sess variable in open_channel was not entirely
cleared to zero at the start of this function.
This commit ensures that the entire struct is cleared.
Signed-off-by: Francois Berder <fberder@outlook.fr>
|
|
Now that we have Base protocol support, we will be able to check if a given
protocol is really supported by the SCMI server (firmware).
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
SCMI base protocol is mandatory, and once SCMI node is found in a device
tree, the protocol handle (udevice) is unconditionally installed to
the agent. Then basic information will be retrieved from SCMI server via
the protocol and saved into the agent instance's local storage.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
Adding SCMI base protocol makes it inconvenient to hold the agent instance
(udevice) locally since the agent device will be re-created per each test.
Just remove it and simplify the test flows.
The test scenario is not changed at all.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
This is a simple implementation of SCMI base protocol for sandbox.
The main use is in SCMI unit test.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
In SCMI base protocol version 2 (0x20000), new interfaces,
BASE_SET_DEVICE_PERMISSIONS/BASE_SET_PROTOCOL_PERMISSIONS/
BASE_RESET_AGENT_CONFIGURATION, were added. Moreover, the api of
BASE_DISCOVER_AGENT was changed to support self-agent discovery.
So the driver expects SCMI firmware support version 2 of base protocol.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
SCMI base protocol is mandatory according to the SCMI specification.
With this patch, SCMI base protocol can be accessed via SCMI transport
layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported.
This is because U-Boot doesn't support interrupts and the current transport
layers are not able to handle asynchronous messages properly.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
This framework allows SCMI protocols to be installed and bound to the agent
so that the agent can manage and utilize them later.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
Move the location of scmi_bind_protocols() backward for changes
in later patches.
There is no change in functionality.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
In sandbox scmi agent, channels are not used at all. But in this patch,
dummy channels are supported in order to test protocol-specific channels.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
SCMI specification allows any protocol to have its own channel for
the transport. While the current SCMI driver may assign its channel
from a device tree, the core function, devm_scmi_process_msg(), doesn't
use a protocol's channel, but always use an agent's channel.
With this commit, devm_scmi_process_msg() tries to find and use
a protocol's channel. If it doesn't exist, use an agent's.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The commit 85dc58289238 ("firmware: scmi: prepare uclass to pass channel
reference") added an explicit parameter, channel, but it seems to make
the code complex.
Hiding this parameter will allow for adding a generic (protocol-agnostic)
helper function, i.e. for PROTOCOL_VERSION, in a later patch.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
When setting up boot media to load the TIFS binary in legacy boot flow
(followed by J721E), get_timer() is called which calls dm_timer_init()
which then gets the tick-timer: mcu_timer0. mcu_timer0 uses k3_clks
(clock controller) and k3_pds (power controller) from the dmsc node that
forces probe of the ti_sci driver of TIFS that hasn't been loaded yet!
Running ti_sci_cmd_get_revision from the probe leads to panic since no
TIFS and board config binaries have been loaded yet. Resolve this by
moving ti_sci_cmd_get_revision to ti_sci_get_handle_from_sysfw as a
common point of invocation for both legacy and combined boot flows.
Before doing this, it is important to go through whether any sync points
exist where revision is needed before ti_sci_get_handle_from_sysfw is
invoked. Going through the code along with boot tests on both flows
ensures that there are none.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Add firmware API to check if given feature is supported.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Link: https://lore.kernel.org/r/20230811054829.13162-2-ashok.reddy.soma@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
replace info logs with debug logs
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
A Sandbox test is provided for the armffa command.
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
This reverts commit d927d1a80843e1c3e2a3f0b8f6150790bef83da1, reversing
changes made to c07ad9520c6190070513016fdb495d4703a4a853.
These changes do not pass CI currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
scmi_to_linux_errno() is set to return an appropriate errno
which corresponds to a given SCMI status code.
But the current implementation always returns the same value.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
Xilinx changes for v2023.10-rc1
global:
- Use proper U-Boot project name
Fix sparse warnings in zynqmp-clk, zynqmp handoff, board
cmd:
- Cover incorrect 0 length entries
Versal NET:
- Add bootmode logic
- Support SPP production version
- Add loadpdi command
ZynqMP:
- Clear pmufw node command ID handling
- Change power domain behavior around zynqmp_pmufw_node()
- Fix zynqmp cmd return values and pmufw command
- Fix R5 tcm init and modes
mmc:
- Sync Versal NET emmc DT binding
pcie:
- Add support for ZynqMP PCIe root port
video:
- Add support for ZynqMP DP
tools:
- Fix debug message in relocate-rela
|
|
Also print more arguments not just ID when xilinx_pm_request is called.
It helps to decode what firmware is asked to do.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/54928d061da75bd972a3b6a1219204e730b49225.1685619271.git.michal.simek@amd.com
|
|
Store the driver data in the data section to make the data usable before
relocation. Additionally mark the driver data static to restrict the
access.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-5-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Move the permission to change a config object message from
zynqmp_pmufw_load_config_object function to zynqmp_pmufw_node function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-4-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Remove the redundant child device bind from the driver bind function and
rely on the post_bind of the class which calls the same function.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-2-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Return a common -EACCES error value instead of a positive private error
value XST_PM_NO_ACCESS (2002) in zynqmp_pmufw_load_config_object
function if the config object is not loadable to simplify the error
checking.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-1-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
The "Message not acknowledged" error message is missing a line feed,
leading to the console log getting garbled and joined together with
whatever the next output is in case this error happens:
"ti_sci system-controller@44043000: Message not acknowledgedAuthentication failed!"
Fix ths by adding the missing linefeed character.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
|
|
It is possible that cpu core may reset before relocation with PSCI reset
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Building U-Boot SPL with CLK_SCMI and SCMI_FIRMWARE Kconfig options
enabled and SPL_FIRMWARE disabled result in the following error.
drivers/clk/clk_scmi.o: in function `scmi_clk_gate':
drivers/clk/clk_scmi.c:84: undefined reference to `devm_scmi_process_msg'
drivers/clk/clk_scmi.c:88: undefined reference to `scmi_to_linux_errno'
drivers/clk/clk_scmi.o: in function `scmi_clk_get_rate':
drivers/clk/clk_scmi.c:113: undefined reference to `devm_scmi_process_msg'
drivers/clk/clk_scmi.c:117: undefined reference to `scmi_to_linux_errno'
drivers/clk/clk_scmi.o: in function `scmi_clk_set_rate':
drivers/clk/clk_scmi.c:139: undefined reference to `devm_scmi_process_msg'
drivers/clk/clk_scmi.c:143: undefined reference to `scmi_to_linux_errno'
drivers/clk/clk_scmi.o: in function `scmi_clk_probe':
drivers/clk/clk_scmi.c:157: undefined reference to `devm_scmi_of_get_channel'
make[1]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1
make: *** [Makefile:2043: spl/u-boot-spl] Error 2
Add Kconfig option so that CLK_SCMI can be disabled in SPL to fix this.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Acked-by: Andrew Davis <afd@ti.com>
|
|
Introduce the bare minimum SD and UART support for the am62a sk.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
In scmi firmware driver, it is better to bind the scmi protocol driver
"scmi_voltage_domain" with the node name of the protocol 17 and not
the sub-node named "regulator", because is a fixed string which doesn't
provide information and because it is not aligned with the other scmi
protocol nodes.
For example on stm32mp135f-dk board with device tree in stm32mp131.dtsi
scmi: scmi {
compatible = "linaro,scmi-optee";
#address-cells = <1>;
#size-cells = <0>;
linaro,optee-channel-id = <0>;
shmem = <&scmi_shm>;
scmi_clk: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
scmi_reset: protocol@16 {
reg = <0x16>;
#reset-cells = <1>;
};
scmi_voltd: protocol@17 {
reg = <0x17>;
scmi_regu: regulators {
#address-cells = <1>;
#size-cells = <0>;
scmi_reg11: voltd-reg11 {
reg = <VOLTD_SCMI_REG11>;
regulator-name = "reg11";
};
scmi_reg18: voltd-reg18 {
reg = <VOLTD_SCMI_REG18>;
regulator-name = "reg18";
};
scmi_usb33: voltd-usb33 {
reg = <VOLTD_SCMI_USB33>;
regulator-name = "usb33";
};
};
};
};
Before the patch:
> dm tree
scmi_agent 0 [ + ] scmi-over-optee |-- scmi
clk 1 [ + ] scmi_clk | |-- protocol@14
...
reset 1 [ ] scmi_reset_domain | |-- protocol@16
nop 2 [ + ] scmi_voltage_domain | `-- regulators
regulator 0 [ + ] scmi_regulator | |-- voltd-reg11
regulator 1 [ + ] scmi_regulator | |-- voltd-reg18
regulator 2 [ + ] scmi_regulator | |-- voltd-usb33
...
after the patch:
> dm tree
scmi_agent 0 [ + ] scmi-over-optee |-- scmi
clk 1 [ + ] scmi_clk | |-- protocol@14
...
reset 1 [ ] scmi_reset_domain | |-- protocol@16
nop 2 [ + ] scmi_voltage_domain | `-- protocol@17
regulator 0 [ + ] scmi_regulator | |-- voltd-reg11
regulator 1 [ + ] scmi_regulator | |-- voltd-reg18
regulator 2 [ + ] scmi_regulator | |-- voltd-usb33
...
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
|
