summaryrefslogtreecommitdiff
path: root/include/linux/soc
AgeCommit message (Collapse)Author
2020-07-13soc: ti: k3-ringacc: Add an API to request pair of ringsVignesh Raghavendra
Add new API k3_ringacc_request_rings_pair() to request pair of rings at once, as in the most case Rings are used with DMA channels which required to request pair of rings - one to feed DMA with descriptors (TX/RX FDQ) and one to receive completions (RX/TX CQ). This will allow to simplify Ringacc API users. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-05-18common: Drop linux/bitops.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop linux/bug.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-03-03firmware: tisci: Drop all deprecated messagesLokesh Vutla
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>
2019-12-09dma: ti: k3-udma: Implement dma_get_cfg() interfaceVignesh Raghavendra
Implement dma_get_cfg() interface to pass flow id information for DMA clients to use. This is needed because on K3 SoCs, CPSW (ethernet) and UDMA (DMA provider) support "flows" within a given RX DMA channel. This allows different network packets to be segregated while using same RX DMA channel. In order for basic ethernet to work, CPSW slave must be aware of the flow ID allocated for the RX channel by the DMA driver. This interface allows CPSW to query flow ID from DMA provider and configure it in CPSW HW. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
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-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-11dma: ti: add driver to K3 UDMAVignesh R
The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P also supports acting as both a UTC and UDMA-C for its internal channels. Channels in the UDMA-P can be configured to be either Packet-Based or Third-Party channels on a channel by channel basis. The initial driver supports: - MEM_TO_MEM (TR mode) - DEV_TO_MEM (Packet mode) - MEM_TO_DEV (Packet mode) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com>
2019-04-11soc: ti: k3: add CPPI5 description and helpersGrygorii Strashko
Add TI Communications Port Programming Interface (CPPI) 5 interface description and helpers Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-04-11soc: ti: k3: add navss ringacc driverGrygorii Strashko
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs. The RINGACC converts constant-address read and write accesses to equivalent read or write accesses to a circular data structure in memory. The RINGACC eliminates the need for each DMA controller which needs to access ring elements from having to know the current state of the ring (base address, current offset). The DMA controller performs a read or write access to a specific address range (which maps to the source interface on the RINGACC) and the RINGACC replaces the address for the transaction with a new address which corresponds to the head or tail element of the ring (head for reads, tail for writes). Since the RINGACC maintains the state, multiple DMA controllers or channels are allowed to coherently share the same rings as applicable. The RINGACC is able to place data which is destined towards software into cached memory directly. Supported ring modes: - Ring Mode - Messaging Mode - Credentials Mode - Queue Manager Mode TI-SCI integration: Texas Instrument's System Control Interface (TI-SCI) Message Protocol now has control over Ringacc module resources management (RM) and Rings configuration. The Ringacc driver manages Rings allocation by itself now and requests TI-SCI firmware to allocate and configure specific Rings only. It's done this way because, Linux driver implements two stage Rings allocation and configuration (allocate ring and configure ring) while TI-SCI Message Protocol supports only one combined operation (allocate+configure). Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vignesh R <vigneshr@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-09-11mailbox: Introduce K3 Secure Proxy DriverLokesh Vutla
Secure Proxy module manages hardware threads that are meant for communication between the processor entities. Adding support for this driver. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@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>