Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29 |
|
#
e752f9b9 |
| 11-May-2023 |
Simon Horman <horms@kernel.org> |
soc: ti: pruss: Allow compile-testing
Allow compile testing of TI PRU-ICSS Subsystem Platform drivers. This allows for improved build-test coverage.
No functional change intended.
Signed-off-by: S
soc: ti: pruss: Allow compile-testing
Allow compile testing of TI PRU-ICSS Subsystem Platform drivers. This allows for improved build-test coverage.
No functional change intended.
Signed-off-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20230511-ti-pruss-compile-testing-v1-1-56291309a60c@kernel.org Signed-off-by: Nishanth Menon <nm@ti.com>
show more ...
|
Revision tags: v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79 |
|
#
13e7accb |
| 11-Nov-2022 |
Thomas Gleixner <tglx@linutronix.de> |
genirq: Get rid of GENERIC_MSI_IRQ_DOMAIN
Adjust to reality and remove another layer of pointless Kconfig indirection. CONFIG_GENERIC_MSI_IRQ is good enough to serve all purposes.
Signed-off-by: Th
genirq: Get rid of GENERIC_MSI_IRQ_DOMAIN
Adjust to reality and remove another layer of pointless Kconfig indirection. CONFIG_GENERIC_MSI_IRQ is good enough to serve all purposes.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20221111122014.524842979@linutronix.de
show more ...
|
Revision tags: v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6 |
|
#
c07f216a |
| 29-Oct-2022 |
Peter Ujfalusi <peter.ujfalusi@gmail.com> |
soc: ti: k3-ringacc: Allow the driver to be built as module
The ring accelerator driver can be built as module since all depending functions are exported.
Signed-off-by: Peter Ujfalusi <peter.ujfal
soc: ti: k3-ringacc: Allow the driver to be built as module
The ring accelerator driver can be built as module since all depending functions are exported.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Nicolas Frayer <nfrayer@baylibre.com> Reviewed-by: Nicolas Frayer <nfrayer@baylibre.com> Link: https://lore.kernel.org/r/20221029075356.7296-1-peter.ujfalusi@gmail.com
show more ...
|
Revision tags: v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
e83b2358 |
| 21-Nov-2020 |
Nishanth Menon <nm@ti.com> |
soc: ti: Kconfig: Drop ARM64 SoC specific configs
With the integration of chip-id detection scheme in kernel[1], there is no specific need to maintain multitudes of SoC specific config options, disc
soc: ti: Kconfig: Drop ARM64 SoC specific configs
With the integration of chip-id detection scheme in kernel[1], there is no specific need to maintain multitudes of SoC specific config options, discussed as per [2], we have deprecated the usage in other places for v5.10-rc1. Drop the configuration for the follow on kernel.
[1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e2fc7 ("soc: ti: add k3 platforms chipid module driver")
Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9 |
|
#
6530cd9b |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem capable of supporting Gigabit Ethernet,
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem capable of supporting Gigabit Ethernet, and is commonly referred to as ICSSG. These SoCs contain typically three ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. The ICSSG2 supports slightly enhanced features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances are limited to MII mode only.
The ICSSGs on K3 AM65x SoCs are in general super-sets of the PRUSS on the AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level differences include different constant tables, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets.
The existing pruss platform driver has been updated to support these new ICSSG instances through new AM65x specific compatibles. A build dependency with ARCH_K3 is added to enable building all the existing PRUSS platform drivers for this ARMv8 platform.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
#
3227c8da |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1, each of which has two PRU processor cores. The two PRU-ICSS
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other with few minor SoC integration differences, and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data RAM size is larger and the number of interrupts coming into MPU INTC is like the instances on AM437x. There are also few other differences attributing to integration in Keystone architecture (like no SYSCFG register or PRCM handshake protocols). Other IP level differences include different constant table, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets.
The existing PRUSS platform driver has been enhanced to support these 66AK2G PRU-ICSS instances through new 66AK2G specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with ARCH_KEYSTONE is added to enable the driver to be built in K2G-only configuration.
Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
#
ae19b8a1 |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
The AM57xx family of SoCs supports two PRU-ICSS instances, each of which has two PRU processor cores. The two PRU-ICSS instances ar
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
The AM57xx family of SoCs supports two PRU-ICSS instances, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other, and are very similar to the PRU-ICSS1 of AM33xx/AM43xx except for a few minor differences like the RAM sizes and the number of interrupts coming into the MPU INTC. They do not have a programmable module reset line unlike those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also preceded by a Crossbar that enables multiple external events to be routed to a specific number of input interrupt events. Any interrupt event directed towards PRUSS needs this crossbar to be setup properly on the firmware side.
The existing PRUSS platform driver has been enhanced to support these AM57xx PRU-ICSS instances through new AM57xx specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with SOC_DRA7XX is also added to enable the driver to be built in AM57xx-only configuration (there is no separate Kconfig option for AM57xx vs DRA7xx).
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
#
78251639 |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs
The AM437x SoCs have two different PRU-ICSS subsystems: PRU-ICSS1 and a smaller PRU-ICSS0. Enhance the PRUSS platform driver to support both
soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs
The AM437x SoCs have two different PRU-ICSS subsystems: PRU-ICSS1 and a smaller PRU-ICSS0. Enhance the PRUSS platform driver to support both the PRU-ICSS sub-systems on these SoCs.
The PRU-ICSS1 on AM437x is very similar to the PRU-ICSS on AM33xx except for few minor differences - increased Instruction RAM, increased Shared Data RAM2, and 1 less interrupt (PRUSS host interrupt 7 which is redirected to the other PRUSS) towards the MPU INTC. The PRU-ICSS0 is a cut-down version of the IP, with less DRAM per PRU, no Shared DRAM etc. It also does not have direct access to L3 bus regions, there is a single interface to L3 for both PRUSS0 and PRUSS1, and it would have to go through the PRUSS1's interface. The PRUSS_SYSCFG register is reserved on PRUSS0, so any external access requires the programming the corresponding PRUSS_SYSCFG register in PRUSS1. It does have its own dedicated I/O lines though. Note that this instance does not support any PRU Ethernet related use cases.
The adaptation uses SoC-specific compatibles in the driver and uses a newly introduced pruss_match_private_data structure and the pruss_get_private_data() function to retrieve a PRUSS instance specific data using a device-name based lookup logic. The reset and the L3 external access are managed by the parent interconnect ti-sysc bus driver so that PRUSS1 and PRUSS0 can be independently supported.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
#
dc112956 |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
The Programmable Real-Time Unit - Industrial Communication Subsystem (PRU-ICSS) is present on various TI SoCs such as AM335x or AM437x or t
soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
The Programmable Real-Time Unit - Industrial Communication Subsystem (PRU-ICSS) is present on various TI SoCs such as AM335x or AM437x or the Keystone 66AK2G. Each SoC can have one or more PRUSS instances that may or may not be identical. For example, AM335x SoCs have a single PRUSS, while AM437x has two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being a cut-down version of the PRUSS1.
The PRUSS consists of dual 32-bit RISC cores called the Programmable Real-Time Units (PRUs), some shared, data and instruction memories, some internal peripheral modules, and an interrupt controller. The programmable nature of the PRUs provide flexibility to implement custom peripheral interfaces, fast real-time responses, or specialized data handling.
The PRU-ICSS functionality is achieved through three different platform drivers addressing a specific portion of the PRUSS. Some sub-modules of the PRU-ICSS IP reuse some of the existing drivers (like davinci mdio driver or the generic syscon driver). This design provides flexibility in representing the different modules of PRUSS accordingly, and at the same time allowing the PRUSS driver to add some instance specific configuration within an SoC.
The PRUSS platform driver deals with the overall PRUSS and is used for managing the subsystem level resources like various memories and the CFG module. It is responsible for the creation and deletion of the platform devices for the child PRU devices and other child devices (like Interrupt Controller, MDIO node and some syscon nodes) so that they can be managed by specific platform drivers. The PRUSS interrupt controller is managed by an irqchip driver, while the individual PRU RISC cores are managed by a PRU remoteproc driver.
The driver currently supports the AM335x SoC, and support for other TI SoCs will be added in subsequent patches.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
Revision tags: v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7 |
|
#
907a2b7e |
| 27-May-2020 |
Grygorii Strashko <grygorii.strashko@ti.com> |
soc: ti: add k3 platforms chipid module driver
The Texas Instruments K3 Multicore SoC platforms have chipid module which is represented by CTRLMMR_xxx_JTAGID register and contains information about
soc: ti: add k3 platforms chipid module driver
The Texas Instruments K3 Multicore SoC platforms have chipid module which is represented by CTRLMMR_xxx_JTAGID register and contains information about SoC id and revision. Bits: 31-28 VARIANT Device variant 27-12 PARTNO Part number 11-1 MFG Indicates TI as manufacturer (0x17) 1 Always 1
This patch adds corresponding driver to identify the TI K3 SoC family and revision, and registers this information with the SoC bus. It is available under /sys/devices/soc0/ for user space, and can be checked, where needed, in Kernel using soc_device_match().
Identification is done by: - checking MFG to be TI ID - retrieving Device variant (revision) - retrieving Part number and convert it to the family - retrieving machine from DT "/model"
Example J721E: # cat /sys/devices/soc0/{machine,family,revision} Texas Instruments K3 J721E SoC J721E SR1.0
Example AM65x: # cat /sys/devices/soc0/{machine,family,revision} Texas Instruments AM654 Base Board AM65X SR1.0
Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
Revision tags: v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13 |
|
#
3277e8aa |
| 15-Jan-2020 |
Grygorii Strashko <grygorii.strashko@ti.com> |
soc: ti: k3: add navss ringacc driver
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RI
soc: ti: k3: add navss ringacc driver
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 TI-SCI Message Protocol supports only one combined operation (allocate+configure).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
Revision tags: v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11 |
|
#
521a503f |
| 17-Jun-2019 |
Arnd Bergmann <arnd@arndb.de> |
soc: ti: fix irq-ti-sci link error
The irqchip driver depends on the SoC specific driver, but we want to be able to compile-test it elsewhere:
WARNING: unmet direct dependencies detected for TI_SCI
soc: ti: fix irq-ti-sci link error
The irqchip driver depends on the SoC specific driver, but we want to be able to compile-test it elsewhere:
WARNING: unmet direct dependencies detected for TI_SCI_INTA_MSI_DOMAIN Depends on [n]: SOC_TI [=n] Selected by [y]: - TI_SCI_INTA_IRQCHIP [=y] && TI_SCI_PROTOCOL [=y]
drivers/irqchip/irq-ti-sci-inta.o: In function `ti_sci_inta_irq_domain_probe': irq-ti-sci-inta.c:(.text+0x204): undefined reference to `ti_sci_inta_msi_create_irq_domain'
Rearrange the Kconfig and Makefile so we build the soc driver whenever its users are there, regardless of the SOC_TI option.
Fixes: 49b323157bf1 ("soc: ti: Add MSI domain bus support for Interrupt Aggregator") Fixes: f011df6179bd ("irqchip/ti-sci-inta: Add msi domain support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net>
show more ...
|
Revision tags: v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5 |
|
#
cff377f7 |
| 22-May-2019 |
Nishanth Menon <nm@ti.com> |
soc: ti: Add Support for J721E SoC config option
Add option to build J721E SoC specific components
Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
Revision tags: v5.1.4 |
|
#
ec8f24b7 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11 |
|
#
49b32315 |
| 30-Apr-2019 |
Lokesh Vutla <lokeshvutla@ti.com> |
soc: ti: Add MSI domain bus support for Interrupt Aggregator
With the system coprocessor managing the range allocation of the inputs to Interrupt Aggregator, it is difficult to represent the device
soc: ti: Add MSI domain bus support for Interrupt Aggregator
With the system coprocessor managing the range allocation of the inputs to Interrupt Aggregator, it is difficult to represent the device IRQs from DT.
The suggestion is to use MSI in such cases where devices wants to allocate and group interrupts dynamically.
Create a MSI domain bus layer that allocates and frees MSIs for a device.
APIs that are implemented: - ti_sci_inta_msi_create_irq_domain() that creates a MSI domain - ti_sci_inta_msi_domain_alloc_irqs() that creates MSIs for the specified device and resource. - ti_sci_inta_msi_domain_free_irqs() frees the irqs attached to the device. - ti_sci_inta_msi_get_virq() for getting the virq attached to a specific event.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
show more ...
|
Revision tags: v5.0.10, v5.0.9, v5.0.8, v5.0.7 |
|
#
5a99ae00 |
| 02-Apr-2019 |
Keerthy <j-keerthy@ti.com> |
soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support
During RTC-only suspend, power is lost to the wkup domain, so we need to save and restore the state of that domain. We also nee
soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support
During RTC-only suspend, power is lost to the wkup domain, so we need to save and restore the state of that domain. We also need to store some information within the RTC registers so that u-boot can do the right thing at powerup.
The state is entered by getting the RTC to bring the pmic_power_en line low which will instruct the PMIC to disable the appropriate power rails after putting DDR into self-refresh mode. To bring pmic_power_en low, we need to get an ALARM2 event. Since we are running from SRAM at that point, it means calculating what the next second is (via ASM) and programming that into the RTC. This patch also adds support for wake up source detection.
Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
show more ...
|
Revision tags: v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4 |
|
#
a869b7b3 |
| 26-Jun-2018 |
Nishanth Menon <nm@ti.com> |
soc: ti: Add Support for AM654 SoC config option
Add option to build AM6 SoC specific components
Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-of
soc: ti: Add Support for AM654 SoC config option
Add option to build AM6 SoC specific components
Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
show more ...
|
Revision tags: v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16 |
|
#
afe761f8 |
| 23-Feb-2018 |
Dave Gerlach <d-gerlach@ti.com> |
soc: ti: Add pm33xx driver for basic suspend support
AM335x and AM437x support various low power modes as documented in section 8.1.4.3 of the AM335x Technical Reference Manual and section 6.4.3 of
soc: ti: Add pm33xx driver for basic suspend support
AM335x and AM437x support various low power modes as documented in section 8.1.4.3 of the AM335x Technical Reference Manual and section 6.4.3 of the AM437x Technical Reference Manual.
DeepSleep0 mode offers the lowest power mode with limited wakeup sources without a system reboot and is mapped as the suspend state in the kernel. In this state, MPU and PER domains are turned off with the internal RAM held in retention to facilitate the resume process. As part of the boot process, the assembly code is copied over to OCMCRAM so it can be executed to turn of the EMIF and put DDR into self refresh.
Both platforms have a Cortex-M3 (WKUP_M3) which assists the MPU in DeepSleep0 entry and exit. WKUP_M3 takes care of the clockdomain and powerdomain transitions based on the intended low power state. MPU needs to load the appropriate WKUP_M3 binary onto the WKUP_M3 memory space before it can leverage any of the PM features like DeepSleep. This loading is handled by the remoteproc driver wkup_m3_rproc.
Communication with the WKUP_M3 is handled by a wkup_m3_ipc driver that exposes the specific PM functionality to be used the PM code.
In the current implementation when the suspend process is initiated, MPU interrupts the WKUP_M3 to let it know about the intent of entering DeepSleep0 and waits for an ACK. When the ACK is received MPU continues with its suspend process to suspend all the drivers and then jumps to assembly in OCMC RAM. The assembly code puts the external RAM in self-refresh mode, gates the MPU clock, and then finally executes the WFI instruction. Execution of the WFI instruction with MPU clock gated triggers another interrupt to the WKUP_M3 which then continues with the power down sequence wherein the clockdomain and powerdomain transition takes place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI execution on WKUP_M3 causes the hardware to disable the main oscillator of the SoC and from here system remains in sleep state until a wake source brings the system into resume path.
When a wakeup event occurs, WKUP_M3 starts the power-up sequence by switching on the power domains and finally enabling the clock to MPU. Since the MPU gets powered down as part of the sleep sequence in the resume path ROM code starts executing. The ROM code detects a wakeup from sleep and then jumps to the resume location in OCMC which was populated in one of the IPC registers as part of the suspend sequence.
Code is based on work by Vaibhav Bedia.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
show more ...
|
Revision tags: v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9 |
|
#
52835d59 |
| 04-Apr-2017 |
Dave Gerlach <d-gerlach@ti.com> |
soc: ti: Add ti_sci_pm_domains driver
Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider to allow each device to attach and associate it's ti-sci-id so that it can be contro
soc: ti: Add ti_sci_pm_domains driver
Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider to allow each device to attach and associate it's ti-sci-id so that it can be controlled through the TI SCI protocol.
This driver implements a simple genpd where each device node has a phandle to the power domain node and also must provide an index which represents the ID to be passed with TI SCI representing the device using a single phandle cell. The driver manually parses the phandle to get the cell value. Through this interface the genpd dev_ops start and stop hooks will use TI SCI to turn on and off each device as determined by pm_runtime usage.
Reviewed-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
Revision tags: v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1 |
|
#
cdd5de50 |
| 22-Sep-2015 |
Dave Gerlach <d-gerlach@ti.com> |
soc: ti: Add wkup_m3_ipc driver
Introduce a wkup_m3_ipc driver to handle communication between the MPU and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the w
soc: ti: Add wkup_m3_ipc driver
Introduce a wkup_m3_ipc driver to handle communication between the MPU and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the wkup_m3_rproc and also handling all IPC which is done using the IPC registers in the control module, a mailbox, and a separate interrupt back from the wkup_m3. A small API is exposed for executing specific power commands, which include configuring for low power mode, request a transition to a low power mode, and status info on a previous transition.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
show more ...
|
Revision tags: v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14 |
|
#
88139ed0 |
| 30-Mar-2014 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
soc: ti: add Keystone Navigator DMA support
The Keystone Navigator DMA driver sets up the dma channels and flows for the QMSS(Queue Manager SubSystem) who triggers the actual data movements across c
soc: ti: add Keystone Navigator DMA support
The Keystone Navigator DMA driver sets up the dma channels and flows for the QMSS(Queue Manager SubSystem) who triggers the actual data movements across clients using destination queues. Every client modules like NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO Engines has its own instance of packet dma hardware. QMSS has also an internal packet DMA module which is used as an infrastructure DMA with zero copy.
Initially this driver was proposed as DMA engine driver but since the hardware is not typical DMA engine and hence doesn't comply with typical DMA engine driver needs, that approach was naked. Link to that discussion - https://lkml.org/lkml/2014/3/18/340
As aligned, now we pair the Navigator DMA with its companion Navigator QMSS subsystem driver.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sandeep Nair <sandeep_n@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5 |
|
#
41f93af9 |
| 28-Feb-2014 |
Sandeep Nair <sandeep_n@ti.com> |
soc: ti: add Keystone Navigator QMSS driver
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navi
soc: ti: add Keystone Navigator QMSS driver
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in: Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Sandeep Nair <sandeep_n@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9 |
|
#
6530cd9b |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem capable of supporting Gigabi
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem capable of supporting Gigabit Ethernet, and is commonly referred to as ICSSG. These SoCs contain typically three ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. The ICSSG2 supports slightly enhanced features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances are limited to MII mode only. The ICSSGs on K3 AM65x SoCs are in general super-sets of the PRUSS on the AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level differences include different constant tables, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. The existing pruss platform driver has been updated to support these new ICSSG instances through new AM65x specific compatibles. A build dependency with ARCH_K3 is added to enable building all the existing PRUSS platform drivers for this ARMv8 platform. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
#
3227c8da |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1, each of which has two PRU processor cores. The
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other with few minor SoC integration differences, and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data RAM size is larger and the number of interrupts coming into MPU INTC is like the instances on AM437x. There are also few other differences attributing to integration in Keystone architecture (like no SYSCFG register or PRCM handshake protocols). Other IP level differences include different constant table, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. The existing PRUSS platform driver has been enhanced to support these 66AK2G PRU-ICSS instances through new 66AK2G specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with ARCH_KEYSTONE is added to enable the driver to be built in K2G-only configuration. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|
#
ae19b8a1 |
| 11-Sep-2020 |
Suman Anna <s-anna@ti.com> |
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs The AM57xx family of SoCs supports two PRU-ICSS instances, each of which has two PRU processor cores. The two PRU-ICSS
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs The AM57xx family of SoCs supports two PRU-ICSS instances, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other, and are very similar to the PRU-ICSS1 of AM33xx/AM43xx except for a few minor differences like the RAM sizes and the number of interrupts coming into the MPU INTC. They do not have a programmable module reset line unlike those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also preceded by a Crossbar that enables multiple external events to be routed to a specific number of input interrupt events. Any interrupt event directed towards PRUSS needs this crossbar to be setup properly on the firmware side. The existing PRUSS platform driver has been enhanced to support these AM57xx PRU-ICSS instances through new AM57xx specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with SOC_DRA7XX is also added to enable the driver to be built in AM57xx-only configuration (there is no separate Kconfig option for AM57xx vs DRA7xx). Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
show more ...
|