summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2020-01-14firmware: Remove probe which is causing extra bindAshok Reddy Soma
Remove probe function dm_scan_fdt_dev from zynqmp-firmware driver. It is just binding its subnode zynqmp-clk. As a result one extra node is showing up in dm tree. This is not required, it is anyway bound from it's own zynqmp-clk driver. Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-12-02common: Move enable/disable_interrupts out of common.hSimon Glass
Move these two functions into the irq_funcs.h header file. Also move interrupt_handler_t as this is used by the irq_install_handler() function. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-10-24firmware: zynqmp: Clean up zynqmp_power_probeMichal Simek
Fix error debug messages to be more accurate and aligned with debug message style in the whole file. And do not initialize ret variable because it is initialized later on and it is just additional step. Fixes: 1327d1678bd2 ("firmware: zynqmp: Add zynqmp-power support") Reported-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
2019-10-24firmware: zynqmp: Report error when xilinx_pm_request called from EL3Michal Simek
Function should report error when called in EL3 context. Also report it as error instead 0 (success). Reported-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
2019-10-24arm64: zynqmp: Convert invoke_smc() to xilinx_pm_request()Michal Simek
Remove macros which use PM_SIP_SVC offset and convert invoke_smc() to xilinx_pm_request() which do calculation with PM_SIP_SVC already. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-24arm64: versal: Rename versal_pm_request to xilinx_pm_requestMichal Simek
Use generic name instead of Versal specific because this should be also used on ZynqMP. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-24arm64: xilinx: Move firmware functions from platform to driverMichal Simek
versal_pm_request() and invoke_smc() are almost the same. Only one difference is that versal_pm_request is adding PM_SIP_SVC offset to api_id. The patch is moving platform implementation to firmware driver code for synchronization. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
2019-10-08arm64: zynqmp: Use mailbox driver for PMUFW config loadingMichal Simek
With new mailbox driver PMUFW configuration object can be loaded via the same interface and there is no need to have pmu_ipc.c completely. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
2019-10-08firmware: zynqmp: Separate function for sending message via mailboxMichal Simek
U-Boot running in EL3 can't use SMC that's why there is a need to talk to PMUFW directly via mailbox. The same logic is applied to all functions which need to talk to PMUFW that's why move this logic to separate function to avoid code duplication. Also SMC request ID can be composed from PM_SIP_SVC offset that's why ZYNQMP_SIP_SVC_GET_API_VERSION macro can be removed completely. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-08firmware: zynqmp: create firmware headerIbai Erkiaga
New firmware header to place firmware specific macro and function declarations. The patch also moves the macros defining PM operations as well as some helper macros. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-08firmware: zynqmp: get fw version with mailbox driverIbai Erkiaga
Implements the function to get PMU Firmware version using the mailbox driver or smc call based on if running SPL or not. Additionally gets version as part of the ZynqMP Firmware driver probing Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-08firmware: zynqmp: Add zynqmp-power supportIbai Erkiaga
zynqmp-power driver for ZynqMP to handle the communication with the PMU firmware. Firmware driver just probes subnodes and power driver handles communication with PMU using the IPI mailbox driver. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-08clk: versal: Add clock driver supportSiva Durga Prasad Paladugu
This patch adds clock driver support for Versal platform. The clock driver queries and performs clock operations using PLM firmware by communicating with it using SMC calls. Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-08zynqmp: firmware: Add Xilinx ZynqMP firmware driverRajan Vaja
Add simple ZynqMP firmware drive to populate child nodes under zynqmp_firmware DT node. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-08-12firmware: ti_sci: Parse all resource ranges even if some is not availableVignesh Raghavendra
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 <peter.ujfalusi@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-29Merge https://gitlab.denx.de/u-boot/custodians/u-boot-socfpgaTom Rini
- Various gen5 fixes
2019-07-26firmware: ti_sci: Add a command for releasing all exclusive devicesLokesh Vutla
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 <lokeshvutla@ti.com>
2019-07-26firmware: ti_sci: Add processor shutdown API methodAndreas Dannenberg
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 <dannenberg@ti.com>
2019-07-26firmware: ti_sci: Allow for device shared and exclusive requestsLokesh Vutla
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 <lokeshvutla@ti.com>
2019-07-21spl: kconfig: separate sysreset and firmware drivers from miscSimon Goldschmidt
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 <simon.k.r.goldschmidt@gmail.com>
2019-05-03firmware: ti_sci: Always request response from firmwareAndrew F. Davis
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 <afd@ti.com> Tested-by: Alejandro Hernandez <ajhernandez@ti.com> Acked-by: Nishanth Menon <nm@ti.com>
2019-05-03firmware: ti_sci: Fix TISCI mailbox receive timeout handlingAndreas Dannenberg
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 <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-26firmware: ti_sci: Modify auth_boot TI-SCI API to match new versionAndrew F. Davis
SYSFW version 2019.01 introduces a slightly modified version of this API, add support for it here. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
2019-04-26firmware: ti_sci: Add support for firewall managementAndrew F. Davis
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 <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
2019-04-12firmware: Add support for querying msmc memoryLokesh Vutla
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 <lokeshvutla@ti.com>
2019-04-11firmware: ti_sci: Add support for NAVSS resource managementGrygorii Strashko
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 <peter.ujfalusi@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Vignesh R <vigneshr@ti.com>
2018-12-12firmware: psci: introduce SPL_ARM_PSCI_FWPeng Fan
Introduce a new macro SPL_ARM_PSCI_FW Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Stefano Babic <sbabic@denx.de>
2018-12-02efi_loader: PSCI reset and shutdownHeinrich Schuchardt
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 <xypron.glpk@gmx.de> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Tested-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-29dm: test: Add "/firmware" node scan testRajan Vaja
Add a test which verifies that all subnodes under "/firmware" nodes are scanned. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> 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 <sjg@chromium.org>
2018-09-29firmware: Add FIRMWARE config prompt stringRajan Vaja
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 <rajan.vaja@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-09-11dm: firmware: Automatically bind child devicesAndreas Dannenberg
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 <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11firmware: ti_sci: Add support for processor control servicesLokesh Vutla
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 <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11firmware: ti_sci: Add support for reboot core serviceAndreas Dannenberg
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 <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2018-09-11firmware: ti_sci: Add support for clock controlLokesh Vutla
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 <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2018-09-11firmware: ti_sci: Add support for device controlAndreas Dannenberg
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 <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2018-09-11firmware: ti_sci: Add support for board configurationAndreas Dannenberg
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 <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11firmware: Add basic support for TI System Control Interface (TI SCI) protocolLokesh Vutla
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 <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini
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 <trini@konsulko.com>
2018-03-05libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>Masahiro Yamada
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 <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-12-04drivers: firmware: psci: use pr_* log functions instead of printf()Masahiro Yamada
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 <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-06-01dm: core: Rename of_device_is_compatible()Simon Glass
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 <sjg@chromium.org>
2017-06-01dm: core: Replace of_offset with accessor (part 2)Simon Glass
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 <sjg@chromium.org>
2017-06-01dm: Fix up inclusion of common.hSimon Glass
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 <sjg@chromium.org>
2017-06-01dm: Use dm.h header when driver mode is usedSimon Glass
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 <sjg@chromium.org>
2017-04-18sysreset: psci: support system reset in a generic way with PSCIMasahiro Yamada
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 <yamada.masahiro@socionext.com>