summaryrefslogtreecommitdiffstats
path: root/sys/sys/intr.h
Commit message (Collapse)AuthorAgeFilesLines
* MFC r304459,r305527:mmel2016-11-051-3/+36
| | | | | | | | | | | | | | | | | | r304459: INTRNG: Rework handling with resources. Partially revert r301453. - Read interrupt properties at bus enumeration time and store it into global mapping table. - At bus_activate_resource() time, given mapping entry is resolved and connected to real interrupt source. A copy of mapping entry is attached to given resource. - At bus_setup_intr() time, mapping entry stored in resource is used for delivery of requested interrupt configuration. - For MSI/MSIX interrupts, mapping entry is created within pci_alloc_msi()/pci_alloc_msix() call. - For legacy PCI interrupts, mapping entry must be created within pcib_route_interrupt() by pcib driver itself. r305527: Fix MIPS INTRNG (both FDT and non-FDT) behaviour broken by r304459
* Remove temporary solution for storing interrupt mapping data asskra2016-06-071-14/+0
| | | | | | it's not needed after r301451 and follow-ups r301453, r301539. This makes INTRNG clean of all additions related to various buses.
* INTRNG: As follow up of r301451, implement mapping and configurationmmel2016-06-071-10/+0
| | | | | | | of gpio pin interrupts by new way. Note: This removes last consumer of intr_ddata machinery and we remove it in separate commit.
* INTRNG - change the way how an interrupt mapping data are providedskra2016-06-051-10/+1
| | | | | | | | to the framework in OFW (FDT) case. This is a follow-up to r301451. Differential Revision: https://reviews.freebsd.org/D6634
* (1) Add a new bus method to get a mapping data for an interrupt.skra2016-06-051-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUS_MAP_INTR() is used to get an interrupt mapping data according to provided hints. The hints could be modified afterwards, but only if mapping data was allocated. This method is intended to be called before BUS_ALLOC_RESOURCE(). An interrupt mapping data describes an interrupt - hardware number, type, configuration, cpu binding, and whatever is needed to setup it. (2) Introduce a method which allows storing of an additional data in struct resource to be available for bus drivers. This method is convenient in two ways: - there is no need to rework existing bus drivers as they can simply be extended to provide an additional data, - there is no need to modify any existing bus methods as struct resource is already passed to them as argument and thus stored data is simply accessible by other bus drivers. For now, implement this method only for INTRNG. This is motivated by needs of modern SOCs where hardware initialization is not straightforward and resources descriptions are complex, opaque for everyone but provider, and may vary from SOC to SOC. Typical situation is that one bus driver can fetch a resource description for its child device, but it's opaque for this driver. Another bus driver knows a provider for this kind of resource and can pass this resource description to it. In fact, something like device IVARS would be perfect for that if implemented generally enough. Unfortunatelly, IVARS are usable only by their owners now. Only owner knows its IVARS layout, thus other bus drivers are not able to use them. Differential Revision: https://reviews.freebsd.org/D6632
* Add an interface to handle interrupt controllers that have a contiguousandrew2016-06-031-0/+6
| | | | | | | | | | | | | | | range of interrupts they pass to a second controller driver to handle. The parent driver is expected to detect when one of these interrupts has been triggered and call intr_child_irq_handler to pass the interrupt to a child. The children controllers are then expected to manage the range by allocating interrupts as needed. This will initially be used by the ARM GICv3 driver, but is is expected to be useful for other driver where this type of allocation applies. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6436
* Return the struct intr_pic pointer from intr_pic_register. This will beandrew2016-05-181-1/+1
| | | | | | | | needed in later changes where we may not be able to lock the pic list lock to perform a lookup, e.g. from within interrupt context. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation
* Introduce MSI and MSI-X support to intrng. This adds a new msi deviceandrew2016-05-161-0/+8
| | | | | | | | | | | | interface with 5 methods to mirror the 5 MSI/MSI-X methods in the pcib interface. The pcib driver will need to perform a device specific lookup to find the MSI controller and pass this to intrng as the xref. Intrng will finally find the controller and have it handle the requested operation. Obtained from: ABT Systems Ltd MFH: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D5985
* INTRNG - redefine struct intr_map_data to avoid headers pollution. Eachskra2016-05-051-15/+10
| | | | | | | | | | | | | | | | struct associated with some type defined in enum intr_map_data_type must have struct intr_map_data on the top of its own definition now. When such structs are used, correct type and size must be filled in. There are three such structs defined in sys/intr.h now. Their definitions should be moved to corresponding headers by follow-up commits. While this change was propagated to all INTRNG like PICs, pic_map_intr() method implementations were corrected on some places. For this specific method, it's ensured by a caller that the 'data' argument passed to this method is never NULL. Also, the return error values were standardized there.
* INTRNG: Define 'INTR_IRQ_INVALID' constant and use it consistentlymmel2016-04-281-0/+2
| | | | as error indicator.
* GPIO: Add support for gpio pin interrupts.mmel2016-04-281-0/+10
| | | | | | | | | Add new function gpio_alloc_intr_resource(), which allows an allocation of interrupt resource associated to given gpio pin. It also allows to specify interrupt configuration. Note: This functionality is dependent on INTRNG, and must be implemented in each GPIO controller.
* Implement intr_isrc_init_on_cpu() and use it to replace very sameskra2016-04-071-0/+4
| | | | | | code implemented in every interrupt controller driver running SMP. This function returns true, if provided ISRC should be enabled on given cpu.
* Remove FDT specific parts from INTRNG. Change its interface to make itskra2016-04-041-61/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | universal. (1) New struct intr_map_data is defined as a container for arbitrary description of an interrupt used by a device. Typically, an interrupt number and configuration relevant to an interrupt controller is encoded in such description. However, any additional information may be encoded too like a set of cpus on which an interrupt should be enabled or vendor specific data needed for setup of an interrupt in controller. The struct intr_map_data itself is meant to be opaque for INTRNG. (2) An intr_map_irq() function is created which takes an interrupt controller identification and struct intr_map_data as arguments and returns global interrupt number which identifies an interrupt. (3) A set of functions to be used by bus drivers is created as well as a corresponding set of methods for interrupt controller drivers. These sets take both struct resource and struct intr_map_data as one of the arguments. There is a goal to keep struct intr_map_data in struct resource, however, this way a final solution is not limited to that. (4) Other small changes are done to reflect new situation. This is only first step aiming to create stable interface for interrupt controller drivers. Thus, some temporary solution is taken. Interrupt descriptions for devices are stored in INTRNG and two specific mapping function are created to be temporary used by bus drivers. That's why the struct intr_map_data is not opaque for INTRNG now. This temporary solution will be replaced by final one in next step. Differential Revision: https://reviews.freebsd.org/D5730
* Generalize IPI support for ARM intrng and use it for interruptskra2016-03-241-4/+4
| | | | | | | | | | | | | | | controller IPI provider. New struct intr_ipi is defined which keeps all info about an IPI: its name, counter, send and dispatch methods. Generic intr_ipi_setup(), intr_ipi_send() and intr_ipi_dispatch() functions are implemented. An IPI provider must implement two functions: (1) an intr_ipi_send_t function which is able to send an IPI, (2) a setup function which initializes itself for an IPI and calls intr_ipi_setup() with appropriate arguments. Differential Revision: https://reviews.freebsd.org/D5700
* Mark other parts of interrupt framework as INTR_SOLO option specific.skra2016-03-011-0/+2
| | | | | | | | | Note that isrc_arg member of struct intr_irqsrc is used only for INTR_SOLO and IPI filter. This should be remembered if IPI filters and their arguments will be stored on another place. This option could be unusable very soon, if interrupt controllers implementations will not be implemented considering it.
* Move IPI related parts back to (ARM) machine specific file now, whenskra2016-02-271-5/+14
| | | | | | | | | | | | | | | the interrupt framework is also going to be used by another (MIPS) architecture. IPI implementations may vary much across different architectures. An IPI implementation should still define INTR_IPI_COUNT and use intr_ipi_setup_counters() to setup IPI counters which are inside of intrcnt[] and intrnames[] arrays. Those are used for sysctl and ddb. Then, intr_ipi_increment_count() should be used to increment obtained counter. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D5459
* Break out the shared bits of the arm intrng definitions into sys/intr.h;adrian2016-02-101-0/+130
leave the machine dependent bits in sys/arm/. This is in preparation for MIPS INTRNG work. Submitted by: Stanislav Galabov <sgalabov@gmail.com>
OpenPOWER on IntegriCloud