| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The commit c18a938bdbac ("arm64: dts: ti: k3-am65-main: Add hwspinlock
node") had previously added the HwSpinlock node directly under the
cbass_main interconnect node even though it is connected on the Main
NavSS local interconnect. The Main NavSS interconnect is represented
as its own interconnect node, so move this node under the main_navss
interconnect node.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
| |
The OMAP HwSpinlock driver is reused for supporting the HwSpinlock
IP within K3 platforms. So, enable both the HwSpinlock core and the
OMAP HwSpinlock driver in the rpmsg config file. There are currently
no direct users of the HwSpinlock IP, but the built-in is the
preferred choice for this driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Main NavSS block on AM65x SoCs contains a HwSpinlock IP instance
that is similar to the IP on some OMAP SoCs. Add the DT node for this
on AM65x SoCs. The node is present within the NavSS block, and is
added as a child node under the cbass_main node.
NOTE:
The node should be moved into a navss_main interconnect node if the
local interconnect of Main NavSS is represented as a child node of
the cbass_main interconnect node in the future.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
| |
The HwSpinlock IP is also present on the newer TI K3 AM65x family of
SoCs. Reuse the existing OMAP Hwspinlock driver to extend the support
for this IP on K3 AM65x SoCs as well.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
| |
The TI K3 AM65x family of SoCs have a HwSpinlock IP that is based
on the existing HwSpinlock IP present in OMAP architecture based
SoCs. Update the existing OMAP HwSpinlock binding for this IP on
TI K3 AM65x SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
| |
Add a debug level trace statement in the OMAP HwSpinlock driver
probe function to print a successful registration.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
| |
Add the RPMsg domain config fragment file v8_ipc.cfg file for
all the defconfigs in the v8 defconfig map file, so that the
various RPMsg related drivers can be enabled and built using
the defconfig builder tool for K3 platforms.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
| |
Add an initial IPC/RPMsg domain config fragment file specifically for
v8 platforms. This will form the foundation for adding all the RPMsg
related module configurations for TI K3 platforms.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
| |
Add the RPMsg domain config fragment file ipc.cfg file for all the
defconfigs in the defconfig map file, so that the various RPMsg
related drivers can be enabled and built using the defconfig builder
tool.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the initial IPC/RPMsg domain config fragment file. This will
form the foundation for adding all the RPMsg related module
configurations, to be used by the TI Linux integration kernel.
Also, enable the fully upstreamed (on OMAP2+ SoCs) OMAP HwSpinlock
and OMAP Mailbox drivers including the corresponding HwSpinlock and
Mailbox cores. These are chosen to be built-in as it is the preferred
choice for these drivers.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into hwspinlock-linux-4.19.y
Pull in the platform base tree into the hwspinlock feature tree. The
merge pulls in the necessary board support for all the AM65x boards.
All the other boards are already supported on vanilla 4.19 kernel.
It also pulls in the defconfig_builder infrastructure used by TI
Integration kernels. This allows the required IPC driver support to
be added on the TI K3 family of SoCs.
* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (123 commits)
dmaengine: ti: k3-udma: Try to use the highest TPL channels for MEM_TO_MEM
dmaengine: ti: k3-udma: Only allow MEM_TO_MEM transfer on the main UDMA
ti_config_fragments/defconfig_map.txt: add missing baseport.cfg entries
ti_config_fragments: v8_baseport: Forward port v8_baseport cfg from 4.14
arm64: dts: ti: k3-am6: Add NAVSS and PDMA nodes
dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
dmaengine: ti: New driver for K3 UDMA
dmaengine: ti: Add cppi5 header for UDMA
dt-bindings: dma: ti: Add document for K3 UDMA
dmaengine: Add function to request slave channel from a dma_device
dmaengine: Add support for reporting DMA cached data amount
dmaengine: Add metadata_ops for dma_async_tx_descriptor
dmaengine: doc: Add sections for per descriptor metadata support
soc: ti: k3: add navss ringacc driver
bindings: soc: ti: add documentation for k3 ringacc
firmware: ti_sci: Add resource management APIs for ringacc, psi-l and udma
ti_config_fragments: v8_baseport: enable K3 thermal
arm64: dts: ti: am6: Add VTM node
arm64: dts: ti: am654: Add thermal zones
thermal: k3: Add support for bandgap sensors
...
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When running memcpy test with big buffers:
echo 800000 > /sys/module/dmatest/parameters/test_buf_size
echo 2000 > /sys/module/dmatest/parameters/timeout
echo 20 > /sys/module/dmatest/parameters/iterations
echo 10 > /sys/module/dmatest/parameters/max_channels
echo 1 > /sys/module/dmatest/parameters/run
The throughput with normal channels is:
dmatest: dma1chan2-copy0: summary 200 tests, 0 failures 87 iops 308840 KB/s (0)
Using High Throughput channel with the same setup:
dmatest: dma1chan2-copy0: summary 200 tests, 0 failures 295 iops 1206172 KB/s (0)
The speed increase is about 4x.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
memcpy via the mcu UDMA is much slower compared to main UDMA:
mcu_udma: dmatest: dma0chan0-copy0: summary 200 tests, 0 failures 41 iops 165997 KB/s (0)
main_udma: dmatest: dma1chan2-copy0: summary 200 tests, 0 failures 87 iops 308840 KB/s (0)
We have enough channels on the main UDMA for memcpy, so disable the support
for MEM_TO_MEM on the mcu side.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
baseport.cfg is missing from some defconfig targets. Add it.
Verified that baseport.cfg was present for these targets in
v4.14 based kernel.
Boot tested on DA850 EVM, build tested with ti_sdk_omap2_rt_release
target.
Fixes: 2a38f5aebdae ("ti_config_fragments/defconfig_map.txt: add baseport.cfg")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
|
| |
| |
| |
| |
| |
| | |
Forward port the v8_baseport config fragment from 4.14 kernel.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
Add nodes and sub nodes for both NAVSS (main and mcu) and add the PDMA
nodes as well.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Certain users can not use right now the DMAengine API due to missing
features in the core. Prime example is Networking.
These users can use the glue layer interface to avoid misuse of DMAengine
API and when the core gains the needed features they can be converted to
use generic API.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)
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 is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.
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 / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| | |
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
New binding document for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P).
UDMA-P is introduced as part of the K3 architecture and can be found on
AM65x SoC.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
dma_get_any_slave_channel() would skip using the filter function, which
in some cases needed to be executed before the alloc_chan_resources
callback to make sure that all parameters are provided for the slave
channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A DMA hardware can have big cache or FIFO and the amount of data sitting in
the DMA fabric can be an interest for the clients.
For example in audio we want to know the delay in the data flow and in case
the DMA have significantly large FIFO/cache, it can affect the latenc/delay
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The metadata is best described as side band data or parameters traveling
alongside the data DMAd by the DMA engine. It is data
which is understood by the peripheral and the peripheral driver only, the
DMA engine see it only as data block and it is not interpreting it in any
way.
The metadata can be different per descriptor as it is a parameter for the
data being transferred.
If the DMA supports per descriptor metadata it can implement the attach,
get_ptr/set_len callbacks.
Client drivers must only use either attach or get_ptr/set_len to avoid
misconfiguration.
Client driver can check if a given metadata mode is supported by the
channel during probe time with
dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_CLIENT);
dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_ENGINE);
and based on this information can use either mode.
Wrappers are also added for the metadata_ops.
To be used in DESC_METADATA_CLIENT mode:
dmaengine_desc_attach_metadata()
To be used in DESC_METADATA_ENGINE mode:
dmaengine_desc_get_metadata_ptr()
dmaengine_desc_set_metadata_len()
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
Update the provider and client documentation with details about the
metadata support.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 corresponding support of TI-SCI Ringacc module RM protocol
introduced as option through DT parameters:
- ti,sci: phandle on TI-SCI firmware controller DT node
- ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware spec
if both parameters present - Ringacc driver will configure/free/reset Rings
using TI-SCI Message Ringacc RM Protocol.
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 I-SCI Message
Protocol supports only one combined operation (allocate+configure).
Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
This patch introduces RINGACC device tree bindings.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
TISCI abstracts the management of NAVSS resources, like UDMA channels,
flows, rings.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
K3 thermal driver is disabled by default, so enable it.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
VTM stands for voltage and thermal management. Add the vtm node and
the associated thermal zones on the SoC.
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The am654 SoC has three thermal zones namely MPU0, MPU1 and MCU
zones
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add support for bandgap sensors. Currently reading temperatures
and trend computing is supported.
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add VTM bindings documentation. In the Voltage Thermal
Management Module(VTM), K3 AM654 supplies a voltage
reference and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The analog-to-digital
converter (ADC) produces an output value that is proportional
to the silicon temperature.
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
There are 2 push buttons: SW5 and SW6 that are basically connected to
WKUP_GPIO0_24 and WKUP_GPIO0_27 respectively. Add the respective
nodes and the pinctrl data to set the mode to GPIO and Input.
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| | |
Enable GPIO_DAVINCI for K3 platforms.
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add gpio0 and gpio1 nodes under MAIN domain and gpio0
under WAKEUP domain.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| | |
Add K3 Specific dependencies
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| | |
Fix the compiler warning with ARM64 config enabled
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
commit e5f4b4ba3d223426cdab582f5a67a841f2b01081 upstream
Add DT entries for I2C instances present in AM654 SoC.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
commit 27e0e5f65dd05167283cf707ae89e19630b0289d upstream
Add pinmux for main uart0 that is serves as console on AM654 EVM
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
commit ffff31e50509eaeea12df0ea2513fc648359b6bd upstream
Add pinctrl regions for the main and wkup mmr.
The range for main pinctrl region contains a gap
at offset 0x2e4, and because of this, the pinctrl
range is split into two sections.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
commit 4d82c9ec96fd25cb4c126df2e14862df434ee185 upstream
The dt-bindings header for TI K3 AM6 SoCs define a set of macros for
defining pinmux configs in human readable form, instead of raw-coded
hex values.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
|
| |
| |
| |
| |
| |
| |
| | |
Add DT nodes for the interrupt routers and aggregators in the AM65x SoC.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
Use the am654 specific compatible for dmsc. This allows to use
the am654 specific RM mapping table.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Select all the TISCI dependent interrupt controller drivers
for AM6 SoC.
Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
an interrupt router.
- Allows for multiplexing of events to interrupts.
- Allows for grouping of multiple events to a single interrupt.
Configuration of the interrupt aggregator registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Aggregator driver over TISCI protocol.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
| |
| |
| |
| |
| |
| | |
Add the DT binding documentation for Interrupt Aggregator driver.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for multiplexing of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Router driver over TISCI protocol.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| | |
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Each resource with in the device can be uniquely identified
by a type and subtype as defined by TISCI. Since this is generic
across the devices, resource allocation also can be made generic
instead of each client driver handling the resource. So add helper
apis to manage the resource.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the resource mapping table for AM654 SoC as defined
in http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am6x/resasg_types.html
Introduce a new compatible for AM654 "ti,am654-sci" for using
this resource map table.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|