src/sys/kern/subr_intr.c, branch upstream/11.0.0FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=upstream%2F11.0.02016-06-07T09:03:27ZRemove temporary solution for storing interrupt mapping data as2016-06-07T09:03:27ZSvatopluk Krausskra@FreeBSD.org2016-06-07T09:03:27Zurn:sha1:c4263292fe74079a4dc0d983734e2868fa49180a
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 configuration2016-06-07T05:08:24ZMichal Melounmmel@FreeBSD.org2016-06-07T05:08:24Zurn:sha1:949883bd72f2d6f96c563466a05ec79eac761674
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 provided2016-06-05T16:20:12ZSvatopluk Krausskra@FreeBSD.org2016-06-05T16:20:12Zurn:sha1:ad5244ece1eb60357d5fefa1b17632a25fcd116e
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.2016-06-05T16:07:57ZSvatopluk Krausskra@FreeBSD.org2016-06-05T16:07:57Zurn:sha1:0869297dd95ab9f013c21a078e8e53c68dd3cf9a
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 contiguous2016-06-03T10:13:18ZAndrew Turnerandrew@FreeBSD.org2016-06-03T10:13:18Zurn:sha1:d1605cda2b70cc0279bb01c01ee209e875b48b7b
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
Limit calling pmc_hook to when the interrupt comes while running userspace.2016-05-24T12:06:56ZAndrew Turnerandrew@FreeBSD.org2016-05-24T12:06:56Zurn:sha1:974692e3bfcf71bf3e23dd73ca177d3c4d289b95
We may enable interrupts from within the callback, e.g. in a data abort
during copyin. If we receive an interrupt at that time pmc_hook will be
called again and, as it is handling userspace stack tracing, will hit a
KASSERT as it checks if the trapframe is from userland.
With this I can run hwpmc with intrng on a ThunderX and have it trace all
CPUs.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Add the needed hwpmc hooks to subr_intr.c. This is needed for the correct2016-05-23T15:26:35ZAndrew Turnerandrew@FreeBSD.org2016-05-23T15:26:35Zurn:sha1:df7a2251ccf99f2fa7e1f4b978da34ee3f2a0553
operation of hwpmc on, for example, arm64 with intrng.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Return the struct intr_pic pointer from intr_pic_register. This will be2016-05-18T15:05:44ZAndrew Turnerandrew@FreeBSD.org2016-05-18T15:05:44Zurn:sha1:9346e9130d7ae72b1a6fadb36de85c835074b883
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 device2016-05-16T09:11:40ZAndrew Turnerandrew@FreeBSD.org2016-05-16T09:11:40Zurn:sha1:3fc155dc64bd967aebcde25b51c4210d870718b9
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
Check malloc succeeded in pic_create, with M_NOWAIT it may return NULL.2016-05-09T12:24:39ZAndrew Turnerandrew@FreeBSD.org2016-05-09T12:24:39Zurn:sha1:b48c608386bc54ce249eb1b031894edcf08d79b3
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation