aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mailbox/omap: Simplify mbox_msg_t usageHEADmailbox-linux-4.19.ySuman Anna2019-06-041-6/+2
| | | | | | | | Simplify the mbox_msg_t type definition and the to_omap_mbox_msg macro to use the uintptr_t type that can scale better to both 32-bit and 64-bit platforms. Signed-off-by: Suman Anna <s-anna@ti.com>
* arm64: dts: ti: k3-am65-main: Move mailbox nodes to main_navss interconnectSuman Anna2019-05-311-120/+120
| | | | | | | | | | | All the Mailbox cluster nodes were currently added directly under the cbass_main interconnect node, even though the Mailbox IP is present within the Main NavSS sub-module and is accessible from the MPU through the Main NavSS local interconnect. The Main NavSS interconnect is represented as its own interconnect node, so move all these nodes under the main_navss interconnect node. Signed-off-by: Suman Anna <s-anna@ti.com>
* dt-bindings: mailbox: omap: Update example for TI K3 AM65x SoCsSuman Anna2019-02-051-1/+1
| | | | | | | | Update the current example node for the K3 AM65x SoCs in the OMAP Mailbox bindings to reflect the updated node names and labels in the actual source code. Signed-off-by: Suman Anna <s-anna@ti.com>
* arm64: dts: ti: k3-am65-main: Rename IPC sub-mailboxesSuman Anna2019-02-051-2/+2
| | | | | | | | | | | | | | | The name "mcu" is no longer to be used to represent the R5F processor subsystem, and is being replaced with the name "r5fss". It will continue to be used as a prefix for peripherals that are present within the MCU voltage domain on the TI K3 SoCs. Rename the current sub-mailbox nodes that are used to communicate between the MPU and the two R5F remote processors in the MCU domain accordingly. The name ipc3x is also dropped to keep the node names generic and be agnostic of the RTOS IPC product to be used for future scalability. Signed-off-by: Suman Anna <s-anna@ti.com>
* arm64: dts: ti: k3-am65-main: Add IPC sub-mailbox nodes for R5FsSuman Anna2018-12-121-2/+14
| | | | | | | | | | | | | | | | | | | Add the sub-mailbox nodes that are used to communicate between MPU and the two R5F remote processors present in the MCU domain. The parent mailbox cluster nodes are enabled and the interrupts associated with the Mailbox Cluster User interrupt used by the sub-mailbox nodes are also added. The GIC_SPI interrupt to be used is dynamically allocated and managed by the System Firmware through the ti-sci-irqchip driver. The sub-mailbox nodes utilize the System Mailbox clusters 1 and 2. These sub-mailbox nodes are added to match the hard-coded mailbox configuration used within the TI IPC 3.x software package. The Cortex R5F processor sub-system is assumed to be running in Split mode, so a sub-mailbox node is used by each of the R5F cores. The sub-mailbox node from cluster 1 is used in case of Lockstep mode. Signed-off-by: Suman Anna <s-anna@ti.com>
* arm64: dts: ti: k3-am65-main: Add mailbox cluster nodesSuman Anna2018-12-121-0/+108
| | | | | | | | | | | | | | | | | | | | | | | | The AM65x Main NavSS block contains a Mailbox IP instance with multiple clusters. Each cluster is equivalent to an Mailbox IP instance on OMAP platforms. Add all the Mailbox clusters as their own nodes under the cbass_main node instead of creating an almost empty parent node for the new K3 mailbox IP and the clusters as its child nodes. All these nodes are marked as disabled, and they need to be enabled along with the appropriate child nodes on a need basis. NOTE: 1. The NavSS only has a limited number of interrupts, so all the interrupts generated by a Mailbox IP are not added by default. Only the needed interrupts that are targeted towards the A53 GIC will need to be be added later on when some sub-mailbox child nodes are added. 2. The nodes 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>
* ti_config_fragments: v8_rpmsg: Enable OMAP Mailbox supportSuman Anna2018-12-121-0/+4
| | | | | | | | Add support to build the OMAP Mailbox driver, required for remote processor messaging with the R5F remoteprocs on the TI K3 family of SoCs. The Mailbox driver is chosen to be built-in by default. Signed-off-by: Suman Anna <s-anna@ti.com>
* mailbox/omap: add support for TI K3 SoCsSuman Anna2018-12-123-18/+33
| | | | | | | | | | | | | | | | | | | The TI K3 AM65x family of SoCs have a new Mailbox IP that is based on the existing Mailbox IP present in OMAP architecture based SoCs. Each instance of the legacy OMAP Mailbox IP is now a single cluster within the newer Mailbox IP instance on K3 architecture based SoCs. A single K3 Mailbox IP instance has multiple clusters with each cluster providing the same functionality as the existing OMAP Mailbox IP. Reuse the existing OMAP Mailbox driver to extend the support for this newer IP present within the Main NavSS block on K3 SoCs. The K3 family of SoCs use 64-bit ARMv8 processors for running Linux, so the driver is also enhanced to deal with the differences between the 32-bit message payloads and the 64-bit pointers used by the client drivers. Signed-off-by: Suman Anna <s-anna@ti.com>
* dt-bindings: mailbox: omap: Update bindings for TI K3 AM65x SoCsSuman Anna2018-12-121-8/+42
| | | | | | | | | The TI K3 AM65x family of SoCs have a new Mailbox IP that is based on the existing Mailbox IP present in OMAP architecture based SoCs. Update the existing OMAP Mailbox bindings for this new IP present on TI K3 AM65x SoCs. Signed-off-by: Suman Anna <s-anna@ti.com>
* Merge branch 'hwspinlock-linux-4.19.y' of git://git.ti.com/rpmsg/hwspinlock ↵Suman Anna2018-12-12146-216/+17198
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into mailbox-linux-4.19.y Merge in the hwspinlock feature tree to bring in the defconfig_builder infrastructure and rpmsg domain config fragments used by TI Integration kernels. The merge also brings in the platform tree that adds the board support for all the AM65x boards. This allows the OMAP Mailbox support to be added for the TI K3 family of SoCs. * 'hwspinlock-linux-4.19.y' of git://git.ti.com/rpmsg/hwspinlock: (127 commits) ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file ti_config_fragments: v8_rpmsg: Add RPMsg domain config fragment file ti_config_fragments: defconfig_map: Include RPMsg config fragment ti_config_fragments: rpmsg: Add RPMsg domain config fragment file 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_defconfig_map: Add v8 rpmsg config fileSuman Anna2018-12-111-6/+6
| | | | | | | | | | | | | | | | | | 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>
| * ti_config_fragments: v8_rpmsg: Add RPMsg domain config fragment fileSuman Anna2018-12-111-0/+3
| | | | | | | | | | | | | | | | 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>
| * ti_config_fragments: defconfig_map: Include RPMsg config fragmentSuman Anna2018-12-111-28/+28
| | | | | | | | | | | | | | | | | | 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>
| * ti_config_fragments: rpmsg: Add RPMsg domain config fragment fileSuman Anna2018-12-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Merge branch 'platform-ti-linux-4.19.y' of ↵Suman Anna2018-12-11144-216/+17185
|/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: ti: k3-udma: Try to use the highest TPL channels for MEM_TO_MEMPeter Ujfalusi2018-12-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: ti: k3-udma: Only allow MEM_TO_MEM transfer on the main UDMAPeter Ujfalusi2018-12-031-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ti_config_fragments/defconfig_map.txt: add missing baseport.cfg entriesSekhar Nori2018-11-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ti_config_fragments: v8_baseport: Forward port v8_baseport cfg from 4.14Tero Kristo2018-11-302-6/+137
| | | | | | | | | | | | Forward port the v8_baseport config fragment from 4.14 kernel. Signed-off-by: Tero Kristo <t-kristo@ti.com>
| * arm64: dts: ti: k3-am6: Add NAVSS and PDMA nodesPeter Ujfalusi2018-11-283-19/+189
| | | | | | | | | | | | | | 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>
| * dmaengine: ti: k3-udma: Add glue layer for non DMAengine usersGrygorii Strashko2018-11-287-0/+1412
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: ti: New driver for K3 UDMAPeter Ujfalusi2018-11-285-0/+3567
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: ti: Add cppi5 header for UDMAPeter Ujfalusi2018-11-281-0/+994
| | | | | | | | Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
| * dt-bindings: dma: ti: Add document for K3 UDMAPeter Ujfalusi2018-11-281-0/+134
| | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: Add function to request slave channel from a dma_devicePeter Ujfalusi2018-11-282-4/+8
| | | | | | | | | | | | | | | | | | 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>
| * dmaengine: Add support for reporting DMA cached data amountPeter Ujfalusi2018-11-282-0/+10
| | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: Add metadata_ops for dma_async_tx_descriptorPeter Ujfalusi2018-11-282-0/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dmaengine: doc: Add sections for per descriptor metadata supportPeter Ujfalusi2018-11-282-0/+121
| | | | | | | | | | | | | | Update the provider and client documentation with details about the metadata support. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
| * soc: ti: k3: add navss ringacc driverGrygorii Strashko2018-11-284-0/+1448
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * bindings: soc: ti: add documentation for k3 ringaccGrygorii Strashko2018-11-281-0/+60
| | | | | | | | | | | | | | | | | | | | 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>
| * firmware: ti_sci: Add resource management APIs for ringacc, psi-l and udmaPeter Ujfalusi2018-11-283-0/+1528
| | | | | | | | | | | | | | TISCI abstracts the management of NAVSS resources, like UDMA channels, flows, rings. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
| * ti_config_fragments: v8_baseport: enable K3 thermalKeerthy2018-11-271-0/+3
| | | | | | | | | | | | | | 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>
| * arm64: dts: ti: am6: Add VTM nodeKeerthy2018-11-271-0/+11
| | | | | | | | | | | | | | | | 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>
| * arm64: dts: ti: am654: Add thermal zonesKeerthy2018-11-271-0/+45
| | | | | | | | | | | | | | | | 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>
| * thermal: k3: Add support for bandgap sensorsKeerthy2018-11-273-0/+302
| | | | | | | | | | | | | | | | 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>
| * dt-bindings: thermal: k3: Add VTM bindings documentationKeerthy2018-11-271-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * arm64: dts: ti: am654-base-board: Add gpio_keys nodeKeerthy2018-11-271-0/+27
| | | | | | | | | | | | | | | | 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>
| * arm64: configs: Enable GPIO_DAVINCIKeerthy2018-11-271-0/+1
| | | | | | | | | | | | Enable GPIO_DAVINCI for K3 platforms. Signed-off-by: Keerthy <j-keerthy@ti.com>
| * arm64: dts: ti: am6: Add gpio nodesKeerthy2018-11-273-0/+59
| | | | | | | | | | | | | | | | 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>
| * gpio: Davinci: Add K3 Specific dependenciesKeerthy2018-11-271-1/+1
| | | | | | | | | | | | Add K3 Specific dependencies Signed-off-by: Keerthy <j-keerthy@ti.com>
| * gpio: davinci: Fix the compiler warning with ARM64 config enabledKeerthy2018-11-271-3/+3
| | | | | | | | | | | | Fix the compiler warning with ARM64 config enabled Signed-off-by: Keerthy <j-keerthy@ti.com>
| * arm64: dts: ti: k3-am654-base-board: Add I2C nodesVignesh R2018-11-275-0/+142
| | | | | | | | | | | | | | | | | | 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>
| * arm64: dts: ti: am654-base-board: Add pinmux for main uart0Vignesh R2018-11-271-0/+16
| | | | | | | | | | | | | | | | | | 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>
| * arm64: dts: ti: k3-am65: Add pinctrl regionsTero Kristo2018-11-273-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dt-bindings: pinctrl: k3: Introduce pinmux definitionsVignesh R2018-11-272-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * arm64: dts: ti: am654: Add interrupt controller nodesLokesh Vutla2018-11-272-0/+43
| | | | | | | | | | | | | | 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>
| * arm64: dts: ti: am654: Update compatible for dmscLokesh Vutla2018-11-271-1/+1
| | | | | | | | | | | | | | 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>
| * soc: ti: am6: Enable interrupt controller driversLokesh Vutla2018-11-271-0/+3
| | | | | | | | | | | | | | | | 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>
| * irqchip: ti-sci-inta: Add support for Interrupt Aggregator driverLokesh Vutla2018-11-275-0/+661
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindingsLokesh Vutla2018-11-272-0/+75
| | | | | | | | | | | | Add the DT binding documentation for Interrupt Aggregator driver. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>