u-boot.git/drivers/firmware, branch v2019.04 Unnamed repository; edit this file 'description' to name the repository. firmware: psci: introduce SPL_ARM_PSCI_FW 2018-12-12T17:14:25+00:00 Peng Fan peng.fan@nxp.com 2018-12-09T12:45:45+00:00 cdd7486616d03e1642ba1dacea6f05c10fc97863 Introduce a new macro SPL_ARM_PSCI_FW Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Stefano Babic <sbabic@denx.de> 
Introduce a new macro SPL_ARM_PSCI_FW

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
efi_loader: PSCI reset and shutdown 2018-12-02T20:59:37+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2018-10-18T10:29:40+00:00 81ea00838c682da06637bcf208549095181df337 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> 
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>
dm: test: Add "/firmware" node scan test 2018-09-29T17:49:35+00:00 Rajan Vaja rajan.vaja@xilinx.com 2018-09-19T10:43:46+00:00 31b8217e83a63d1c8c70edcdcdf5aff3b1791640 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> 
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>
firmware: Add FIRMWARE config prompt string 2018-09-29T17:49:35+00:00 Rajan Vaja rajan.vaja@xilinx.com 2018-09-19T10:43:43+00:00 e7a52ba65be227f4fa06b851d1d92af1bef694e0 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> 
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>
dm: firmware: Automatically bind child devices 2018-09-11T12:32:55+00:00 Andreas Dannenberg dannenberg@ti.com 2018-08-27T10:27:38+00:00 aec99c9776d33a1c2218f975a02cb1068cdcf579 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> 
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>
firmware: ti_sci: Add support for processor control services 2018-09-11T12:32:55+00:00 Lokesh Vutla lokeshvutla@ti.com 2018-08-27T10:27:37+00:00 ccbc8b2fddc59f9ec5f487b704195227e4360c29 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> 
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>
firmware: ti_sci: Add support for reboot core service 2018-09-11T12:32:55+00:00 Andreas Dannenberg dannenberg@ti.com 2018-08-27T10:27:36+00:00 f369b0f26cf77921e2a3b8c5ad7dab7e82b246ee 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> 
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>
firmware: ti_sci: Add support for clock control 2018-09-11T12:32:55+00:00 Lokesh Vutla lokeshvutla@ti.com 2018-08-27T10:27:35+00:00 9b87181fd297f38bd52b597a31dc64ba959afdfd 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> 
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>
firmware: ti_sci: Add support for device control 2018-09-11T12:32:55+00:00 Andreas Dannenberg dannenberg@ti.com 2018-08-27T10:27:34+00:00 7bc330452c38db9c01357623eb6785b7ac8866b2 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> 
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>
firmware: ti_sci: Add support for board configuration 2018-09-11T12:32:55+00:00 Andreas Dannenberg dannenberg@ti.com 2018-08-27T10:27:33+00:00 dcfc52ad69db29118bc6658f716d0480d18a0651 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> 
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>