| Age | Commit message (Collapse) | Author |
|---|
|
Do not fail if any of the requested subtypes are not available, but set the
number of resources to 0 and continue parsing the resource ranges.
Based on Linux kernel patch by Peter Ujfalusi <[email protected]>
Signed-off-by: Vignesh Raghavendra <[email protected]>
Reviewed-by: Lokesh Vutla <[email protected]>
|
|
- Various gen5 fixes
|
|
Any host while requesting for a device can request for its exclusive
access. If an exclusive permission is obtained then it is the host's
responsibility to release the device before the software entity on
the host completes its execution. Else any other host's request for
the device will be nacked. So add a command that releases all the
exclusive devices that is acquired by the current host. This should
be used with utmost care and can be called only at the end of the
execution.
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
Add and expose a new processor shutdown API that wraps the two TISCI
messages involved in initiating a core shutdown. The API will first
queue a message to have the DMSC wait for a certain processor boot
status to happen followed by a message to trigger the actual shutdown-
with both messages being sent without waiting or requesting for a
response. Note that the processor shutdown API call will need to be
followed up by user software placing the respective core into either
WFE or WFI mode.
Signed-off-by: Andreas Dannenberg <[email protected]>
|
|
Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw. Current tisci
driver enables this flag for every device requests. But this may not
be true for all the devices. So provide a separate commands in driver
for exclusive and shared device requests.
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
This adds separate kconfig options for drivers/sysreset and
drivers/firmware.
Up to now, CONFIG_SPL_DRIVERS_MISC_SUPPORT added drivers/misc to SPL
build but also added drivers/firmware and drivers/sysreset at the same
time.
Since that is confusing, this patch uses CONFIG_SPL_SYSRESET for
drivers/sysreset and adds CONFIG_SPL_FIRMWARE for
drivers/firmware (and accordingly for the TPL options).
CONFIG_SPL_DRIVERS_MISC_SUPPORT stays for including drivers/misc into
the SPL build (and accordingly for TPL) since there are boards using
non-DM (non UCLASS_MISC) files from drivers/misc. Such boards don't
have CONFIG_SPL_MISC enabled, so cannot use this to include
drivers/misc into the SPL build.
Signed-off-by: Simon Goldschmidt <[email protected]>
|
|
TI-SCI firmware will only respond to messages when the
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages
already do this, set this for the ones that do not.
Signed-off-by: Andrew F. Davis <[email protected]>
Tested-by: Alejandro Hernandez <[email protected]>
Acked-by: Nishanth Menon <[email protected]>
|
|
An earlier commit converted the TISCI receive timeouts to be specified
in ms rather than us however it failed to take this change into account
when passing the actual timeout to be used when invoking the mailbox
receive API. This leads to the actual timeout to be 1,000 times shorter
than expected and as a result certain TISCI operations would fail.
Fix the issue by converting the timeout declared in ms to us on the fly
as expected by the respective API.
Fixes: fd6b40b1ba20 ("firmware: ti_sci: Add support for NAVSS resource management")
Signed-off-by: Andreas Dannenberg <[email protected]>
Reviewed-by: Lokesh Vutla <[email protected]>
|
|
SYSFW version 2019.01 introduces a slightly modified version of this API,
add support for it here.
Signed-off-by: Andrew F. Davis <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Andreas Dannenberg <[email protected]>
|
|
TI-SCI message protocol provides support for controlling the firewall
configurations available in SoC.
Introduce support for the set of TI-SCI message protocol APIs that
provide us with this capability of controlling firewalls.
Signed-off-by: Andrew F. Davis <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Andreas Dannenberg <[email protected]>
|
|
DMSC can use certain amount of msmc memory available in the
system. Also certain part of msmc memory can be marked as L3
cache using board config. But users might not know what size
is being used and the remaining available msmc memory. In order
to fix this TISCI protocol provides a messages that can query
the available msmc memory in the system. Add support for this
message.
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
Texas Instruments' System Control Interface (TI-SCI) Message Protocol
abstracts management of NAVSS resources, like PSI-L pairing and
unpairing, UDMAP tx/rx/flow configuration and Rings.
This patch adds support for requesting and configuring such resources
from TI-SCI firmware.
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Grygorii Strashko <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Vignesh R <[email protected]>
|
|
Introduce a new macro SPL_ARM_PSCI_FW
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Stefano Babic <[email protected]>
|
|
When an operating system started via bootefi tries to reset or power off
this is done by calling the EFI runtime ResetSystem(). On most ARMv8 system
the actual reset relies on PSCI. Depending on whether the PSCI firmware
resides the hypervisor (EL2) or in the secure monitor (EL3) either an HVC
or an SMC command has to be issued.
The current implementation always uses SMC. This results in crashes on
systems where the PSCI firmware is implemented in the hypervisor, e.g.
qemu-arm64_defconfig.
The logic to decide which call is needed based on the device tree is
already implemented in the PSCI firmware driver. During the EFI runtime
the device driver model is not available. But we can minimize code
duplication by merging the EFI runtime reset and poweroff code with
the PSCI firmware driver.
As the same HVC/SMC problem is also evident for the ARMv8 do_poweroff
and reset_misc routines let's move them into the same code module.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Tested-by: Sumit Garg <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Add a test which verifies that all subnodes under "/firmware"
nodes are scanned.
Signed-off-by: Rajan Vaja <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Added 'imply FIRMWARE' to sandbox Kconfig to fix test failures, fixed
ordering of lines in arch/sandbox/dts/test.dts and test/dm/Makefile,
updated #if condition in drivers/firmware/firmware-uclass.c:
Signed-off-by: Simon Glass <[email protected]>
|
|
There is no prompt string for FIRMWARE config. Without this,
FIRMWARE config cannot be enabled through menuconfing or
config file. Fix this by adding prompt summary.
Signed-off-by: Rajan Vaja <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
To support scenarios where a firmware device node has subnodes that
have their own drivers automatically scan the DT and bind those when
the firmware device gets bound.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Andreas Dannenberg <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
TI-SCI message protocol provides support for controlling of various
physical cores available in SoC. In order to control which host is
capable of controlling a physical processor core, there is a processor
access control list that needs to be populated as part of the board
configuration data.
Introduce support for the set of TI-SCI message protocol apis that
provide us with this capability of controlling physical cores.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
Since system controller now has control over SoC power management, it
needs to be explicitly requested to reboot the SoC. Add support for
it.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Andreas Dannenberg <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.
Introduce support for the set of SCI message protocol support that
provide us with this capability.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
TI-SCI message protocol provides support for management of various
hardware entitites within the SoC. Introduce the fundamental
device management capability support to the driver protocol
as part of this change.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
TI-SCI message protocol provides support for board configuration
to assign resources and other board related operations.
Introduce the board configuration capability support to the driver protocol
as part of this change.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Andreas Dannenberg <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
Texas Instrument's System Control Interface (TI SCI) message protocol is
used in Texas Instrument's System on Chip (SoC) such as those in the K3
family AM654 SoC to communicate between various compute processors with
a central system controller entity.
The TI SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.
This is mostly derived from the TI SCI driver in Linux located at
drivers/firmware/ti_sci.c.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Andreas Dannenberg <[email protected]>
|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <[email protected]>
|
|
Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.
This commit moves the header code:
include/libfdt.h -> include/linux/libfdt.h
include/libfdt_env.h -> include/linux/libfdt_env.h
and replaces include directives:
#include <libfdt.h> -> #include <linux/libfdt.h>
#include <libfdt_env.h> -> #include <linux/libfdt_env.h>
Reported-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
In Linux, the warning messages are printed out by pr_warn().
We can use Linux-like log functions in tree-wide.
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The of_ prefix conflicts with the livetree version of this function.
Rename it to avoid problems when we add livetree support.
Signed-off-by: Simon Glass <[email protected]>
|
|
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <[email protected]>
|
|
It is good practice to include common.h as the first header. This ensures
that required features like the DECLARE_GLOBAL_DATA_PTR macro,
configuration options and common types are available.
Fix up some files which currently don't do this. This is necessary because
driver model will soon start using global data and configuration in the
dm/read.h header file, included via dm.h. The gd->fdt_blob value will be
used to access the device tree and CONFIG options will be used to
determine whether to support inline functions in the header file.
Signed-off-by: Simon Glass <[email protected]>
|
|
This header includes things that are needed to make driver build. Adjust
existing users to include that always, even if other dm/ includes are
present
Signed-off-by: Simon Glass <[email protected]>
|
|
If the system is running PSCI firmware, the System Reset function
(func ID: 0x80000009) is supposed to be handled by PSCI, that is,
the SoC/board specific reset implementation should be moved to PSCI.
U-Boot should call the PSCI service according to the arm-smccc
manner.
The arm-smccc is supported on ARMv7 or later. Especially, ARMv8
generation SoCs are likely to run ARM Trusted Firmware BL31. In
this case, U-Boot is a non-secure world boot loader, so it should
not be able to reset the system directly.
Signed-off-by: Masahiro Yamada <[email protected]>
|
