kernel/linux.git/drivers/soc/ti/Kconfig, branch linux-7.0.y

soc: ti: k3-socinfo: Fix compile testing

2026-01-14T16:57:35+00:00

There seems to be nothing preventing this driver from being compile tested so enable that by adding the missing input prompt. Fixes: 907a2b7e2fc7 ("soc: ti: add k3 platforms chipid module driver") Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251127135455.2497-1-johan@kernel.org Signed-off-by: Nishanth Menon

pmdomain: ti: Move and add Kconfig options to the pmdomain subsystem

2023-10-04T21:41:56+00:00

The TI_SCI_PM_DOMAINS Kconfig option belongs closer to its corresponding implementation, hence let's move it from the soc subsystem to the pmdomain subsystem. While at it, let's also add a Kconfig option the omap_prm driver, rather than using ARCH_OMAP2PLUS directly. Cc: Nishanth Menon Cc: Santosh Shilimkar Cc: Tero Kristo Cc: Tony Lindgren Reviewed-by: Dhruva Gole Signed-off-by: Ulf Hansson

soc: ti: pruss: Allow compile-testing

2023-05-17T14:14:02+00:00

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 Link: https://lore.kernel.org/r/20230511-ti-pruss-compile-testing-v1-1-56291309a60c@kernel.org Signed-off-by: Nishanth Menon

Merge tag 'irq-core-2022-12-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2022-12-12T19:21:29+00:00

Pull irq updates from Thomas Gleixner: "Updates for the interrupt core and driver subsystem: The bulk is the rework of the MSI subsystem to support per device MSI interrupt domains. This solves conceptual problems of the current PCI/MSI design which are in the way of providing support for PCI/MSI[-X] and the upcoming PCI/IMS mechanism on the same device. IMS (Interrupt Message Store] is a new specification which allows device manufactures to provide implementation defined storage for MSI messages (as opposed to PCI/MSI and PCI/MSI-X that has a specified message store which is uniform accross all devices). The PCI/MSI[-X] uniformity allowed us to get away with "global" PCI/MSI domains. IMS not only allows to overcome the size limitations of the MSI-X table, but also gives the device manufacturer the freedom to store the message in arbitrary places, even in host memory which is shared with the device. There have been several attempts to glue this into the current MSI code, but after lengthy discussions it turned out that there is a fundamental design problem in the current PCI/MSI-X implementation. This needs some historical background. When PCI/MSI[-X] support was added around 2003, interrupt management was completely different from what we have today in the actively developed architectures. Interrupt management was completely architecture specific and while there were attempts to create common infrastructure the commonalities were rudimentary and just providing shared data structures and interfaces so that drivers could be written in an architecture agnostic way. The initial PCI/MSI[-X] support obviously plugged into this model which resulted in some basic shared infrastructure in the PCI core code for setting up MSI descriptors, which are a pure software construct for holding data relevant for a particular MSI interrupt, but the actual association to Linux interrupts was completely architecture specific. This model is still supported today to keep museum architectures and notorious stragglers alive. In 2013 Intel tried to add support for hot-pluggable IO/APICs to the kernel, which was creating yet another architecture specific mechanism and resulted in an unholy mess on top of the existing horrors of x86 interrupt handling. The x86 interrupt management code was already an incomprehensible maze of indirections between the CPU vector management, interrupt remapping and the actual IO/APIC and PCI/MSI[-X] implementation. At roughly the same time ARM struggled with the ever growing SoC specific extensions which were glued on top of the architected GIC interrupt controller. This resulted in a fundamental redesign of interrupt management and provided the today prevailing concept of hierarchical interrupt domains. This allowed to disentangle the interactions between x86 vector domain and interrupt remapping and also allowed ARM to handle the zoo of SoC specific interrupt components in a sane way. The concept of hierarchical interrupt domains aims to encapsulate the functionality of particular IP blocks which are involved in interrupt delivery so that they become extensible and pluggable. The X86 encapsulation looks like this: |--- device 1 [Vector]---[Remapping]---[PCI/MSI]--|... |--- device N where the remapping domain is an optional component and in case that it is not available the PCI/MSI[-X] domains have the vector domain as their parent. This reduced the required interaction between the domains pretty much to the initialization phase where it is obviously required to establish the proper parent relation ship in the components of the hierarchy. While in most cases the model is strictly representing the chain of IP blocks and abstracting them so they can be plugged together to form a hierarchy, the design stopped short on PCI/MSI[-X]. Looking at the hardware it's clear that the actual PCI/MSI[-X] interrupt controller is not a global entity, but strict a per PCI device entity. Here we took a short cut on the hierarchical model and went for the easy solution of providing "global" PCI/MSI domains which was possible because the PCI/MSI[-X] handling is uniform across the devices. This also allowed to keep the existing PCI/MSI[-X] infrastructure mostly unchanged which in turn made it simple to keep the existing architecture specific management alive. A similar problem was created in the ARM world with support for IP block specific message storage. Instead of going all the way to stack a IP block specific domain on top of the generic MSI domain this ended in a construct which provides a "global" platform MSI domain which allows overriding the irq_write_msi_msg() callback per allocation. In course of the lengthy discussions we identified other abuse of the MSI infrastructure in wireless drivers, NTB etc. where support for implementation specific message storage was just mindlessly glued into the existing infrastructure. Some of this just works by chance on particular platforms but will fail in hard to diagnose ways when the driver is used on platforms where the underlying MSI interrupt management code does not expect the creative abuse. Another shortcoming of today's PCI/MSI-X support is the inability to allocate or free individual vectors after the initial enablement of MSI-X. This results in an works by chance implementation of VFIO (PCI pass-through) where interrupts on the host side are not set up upfront to avoid resource exhaustion. They are expanded at run-time when the guest actually tries to use them. The way how this is implemented is that the host disables MSI-X and then re-enables it with a larger number of vectors again. That works by chance because most device drivers set up all interrupts before the device actually will utilize them. But that's not universally true because some drivers allocate a large enough number of vectors but do not utilize them until it's actually required, e.g. for acceleration support. But at that point other interrupts of the device might be in active use and the MSI-X disable/enable dance can just result in losing interrupts and therefore hard to diagnose subtle problems. Last but not least the "global" PCI/MSI-X domain approach prevents to utilize PCI/MSI[-X] and PCI/IMS on the same device due to the fact that IMS is not longer providing a uniform storage and configuration model. The solution to this is to implement the missing step and switch from global PCI/MSI domains to per device PCI/MSI domains. The resulting hierarchy then looks like this: |--- [PCI/MSI] device 1 [Vector]---[Remapping]---|... |--- [PCI/MSI] device N which in turn allows to provide support for multiple domains per device: |--- [PCI/MSI] device 1 |--- [PCI/IMS] device 1 [Vector]---[Remapping]---|... |--- [PCI/MSI] device N |--- [PCI/IMS] device N This work converts the MSI and PCI/MSI core and the x86 interrupt domains to the new model, provides new interfaces for post-enable allocation/free of MSI-X interrupts and the base framework for PCI/IMS. PCI/IMS has been verified with the work in progress IDXD driver. There is work in progress to convert ARM over which will replace the platform MSI train-wreck. The cleanup of VFIO, NTB and other creative "solutions" are in the works as well. Drivers: - Updates for the LoongArch interrupt chip drivers - Support for MTK CIRQv2 - The usual small fixes and updates all over the place" * tag 'irq-core-2022-12-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (134 commits) irqchip/ti-sci-inta: Fix kernel doc irqchip/gic-v2m: Mark a few functions __init irqchip/gic-v2m: Include arm-gic-common.h irqchip/irq-mvebu-icu: Fix works by chance pointer assignment iommu/amd: Enable PCI/IMS iommu/vt-d: Enable PCI/IMS x86/apic/msi: Enable PCI/IMS PCI/MSI: Provide pci_ims_alloc/free_irq() PCI/MSI: Provide IMS (Interrupt Message Store) support genirq/msi: Provide constants for PCI/IMS support x86/apic/msi: Enable MSI_FLAG_PCI_MSIX_ALLOC_DYN PCI/MSI: Provide post-enable dynamic allocation interfaces for MSI-X PCI/MSI: Provide prepare_desc() MSI domain op PCI/MSI: Split MSI-X descriptor setup genirq/msi: Provide MSI_FLAG_MSIX_ALLOC_DYN genirq/msi: Provide msi_domain_alloc_irq_at() genirq/msi: Provide msi_domain_ops:: Prepare_desc() genirq/msi: Provide msi_desc:: Msi_data genirq/msi: Provide struct msi_map x86/apic/msi: Remove arch_create_remap_msi_irq_domain() ...

genirq: Get rid of GENERIC_MSI_IRQ_DOMAIN

2022-11-17T14:15:20+00:00

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 Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20221111122014.524842979@linutronix.de

soc: ti: k3-ringacc: Allow the driver to be built as module

2022-11-03T06:42:50+00:00

The ring accelerator driver can be built as module since all depending functions are exported. Signed-off-by: Peter Ujfalusi Signed-off-by: Nishanth Menon Tested-by: Nicolas Frayer Reviewed-by: Nicolas Frayer Link: https://lore.kernel.org/r/20221029075356.7296-1-peter.ujfalusi@gmail.com

soc: ti: Kconfig: Drop ARM64 SoC specific configs

2020-11-22T03:22:01+00:00

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 Signed-off-by: Santosh Shilimkar

soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs

2020-09-12T04:43:36+00:00

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 Signed-off-by: Grzegorz Jaszczyk Signed-off-by: Santosh Shilimkar

soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC

2020-09-12T04:43:36+00:00

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 Signed-off-by: Suman Anna Signed-off-by: Grzegorz Jaszczyk Signed-off-by: Santosh Shilimkar

soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs

2020-09-12T04:43:35+00:00

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 Signed-off-by: Grzegorz Jaszczyk Signed-off-by: Santosh Shilimkar