summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/ti_sci.c
Commit message (Collapse)AuthorAgeFilesLines
* dm: treewide: Rename auto_alloc_size members to be shorterSimon Glass2020-12-131-1/+1
| | | | | | | | | | | | This construct is quite long-winded. In earlier days it made some sense since auto-allocation was a strange concept. But with driver model now used pretty universally, we can shorten this to 'auto'. This reduces verbosity and makes it easier to read. Coincidentally it also ensures that every declaration is on one line, thus making dtoc's job easier. Signed-off-by: Simon Glass <sjg@chromium.org>
* firmware: ti_sci: Fix not calling dev_err with a deviceSean Anderson2020-09-301-7/+16
| | | | | | | | | This converts calls to dev_err to get the device from ti_sci_info where appropriate. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Nishanth Menon <nm@ti.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
* firmware: ti_sci: Drop unused structure ti_sci_rm_type_mapLokesh Vutla2020-08-311-49/+3
| | | | | | | struct ti_sci_rm_type_map is no longer used. Drop its definition and its declarations. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* firmware: ti_sci: drop the device ids to resource id translation tableLokesh Vutla2020-08-311-11/+1
| | | | | | | | With ABI 3.0, sysfw deprecated special resource types used for AM65x SoC. Instead started using device id as resource type similar to the convention used in J721E SOC. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* common: Drop linux/bitops.h from common headerSimon Glass2020-05-181-0/+1
| | | | | | Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
* common: Drop log.h from common headerSimon Glass2020-05-181-0/+1
| | | | | | Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
* firmware: tisci: Drop all deprecated messagesLokesh Vutla2020-03-031-77/+0
| | | | | | | | | | | | | | SYSFW v2020.01 and later versions no longer supports the below messages: - TI_SCI_MSG_RM_RING_GET_CFG - TISCI_MSG_RM_UDMAP_TX_CH_GET_CFG 0x1206 - TISCI_MSG_RM_UDMAP_RX_CH_GET_CFG 0x1216 - TISCI_MSG_RM_UDMAP_FLOW_GET_CFG 0x1232 - TISCI_MSG_RM_UDMAP_FLOW_SIZE_THRESH_GET_CFG 0x1233 There are no users in U-Boot for any of the above messages, So drop the support for all the corresponding messages. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* dm: core: Create a new header file for 'compat' featuresSimon Glass2020-02-051-0/+2
| | | | | | | | | | | | At present dm/device.h includes the linux-compatible features. This requires including linux/compat.h which in turn includes a lot of headers. One of these is malloc.h which we thus end up including in every file in U-Boot. Apart from the inefficiency of this, it is problematic for sandbox which needs to use the system malloc() in some files. Move the compatibility features into a separate header file. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Require users of devres to include the headerSimon Glass2020-02-051-0/+1
| | | | | | | | | | At present devres.h is included in all files that include dm.h but few make use of it. Also this pulls in linux/compat which adds several more headers. Drop the automatic inclusion and require files to include devres themselves. This provides a good indication of which files use devres. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
* firmware: ti_sci: Parse all resource ranges even if some is not availableVignesh Raghavendra2019-08-121-3/+10
| | | | | | | | | | 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>
* firmware: ti_sci: Add a command for releasing all exclusive devicesLokesh Vutla2019-07-261-0/+75
| | | | | | | | | | | | | 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>
* firmware: ti_sci: Add processor shutdown API methodAndreas Dannenberg2019-07-261-4/+187
| | | | | | | | | | | | | 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>
* firmware: ti_sci: Allow for device shared and exclusive requestsLokesh Vutla2019-07-261-5/+20
| | | | | | | | | | | | | 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>
* firmware: ti_sci: Always request response from firmwareAndrew F. Davis2019-05-031-5/+6
| | | | | | | | | | 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>
* firmware: ti_sci: Fix TISCI mailbox receive timeout handlingAndreas Dannenberg2019-05-031-1/+1
| | | | | | | | | | | | | | | 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>
* firmware: ti_sci: Modify auth_boot TI-SCI API to match new versionAndrew F. Davis2019-04-261-9/+16
| | | | | | | | | 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>
* firmware: ti_sci: Add support for firewall managementAndrew F. Davis2019-04-261-0/+177
| | | | | | | | | | | | 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>
* firmware: Add support for querying msmc memoryLokesh Vutla2019-04-121-0/+53
| | | | | | | | | | | | 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>
* firmware: ti_sci: Add support for NAVSS resource managementGrygorii Strashko2019-04-111-11/+749
| | | | | | | | | | | | | | 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>
* firmware: ti_sci: Add support for processor control servicesLokesh Vutla2018-09-111-0/+371
| | | | | | | | | | | | | | 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 serviceAndreas Dannenberg2018-09-111-0/+47
| | | | | | | | | | | 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 controlLokesh Vutla2018-09-111-0/+639
| | | | | | | | | | | | | 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 controlAndreas Dannenberg2018-09-111-0/+391
| | | | | | | | | | | 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 configurationAndreas Dannenberg2018-09-111-0/+137
| | | | | | | | | | | 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>
* firmware: Add basic support for TI System Control Interface (TI SCI) protocolLokesh Vutla2018-09-111-0/+448
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>