On 07/22/16 13:53, Andrew Turner wrote:
On Fri, 22 Jul 2016 13:19:32 -0700
John Baldwin <j...@freebsd.org> wrote:
On Thursday, July 21, 2016 10:51:20 PM Nathan Whitehorn wrote:
On 07/21/16 14:35, John Baldwin wrote:
On Thursday, July 21, 2016 01:37:42 PM Andrew Turner wrote:
On Wed, 20 Jul 2016 13:28:53 +0200
Michal Meloun <m...@freebsd.org> wrote:
Dne 19.07.2016 v 17:06 Nathan Whitehorn napsal(a):
2. It partially duplicates the functionality of
OFW_BUS_MAP_INTR(), but is both problematically more general
and less flexible (it has requirements on timing of PIC
attachment vs. driver resource allocation)
OFW_BUS_MAP_INTR() can parse only OFW based data and expect
that parsed data are magicaly stored within the call.
The new method, bus_map_intr(), can parse data from multiple
sources (OFW, UEFI / ACPI, synthetic[gpio device + pin
number]). It also returns parsed data back to caller.
And no, it doesn't add any additional timing requirements .
I've been looking at ACPI on arm64. So far I have not found the
need for this with ACPI as we don't need to send the data to the
interrupt controller driver to be parsed in the way OFW/FDT
needs to.
ACPI though has a gross hack where we call BUS_CONFIG_INTR on the
IRQ in bus_alloc_resource().
I hadn't realized that. It looks like you could do essentially the
same thing we do on PowerPC to clean this up by explicitly mapping
the ACPI interrupt domains to different PICs with varying default
interrupt properties.
What I had advocated in the discussions
leading up to this was to have some sort of opaque structure
containing a set of properties (the sort of thing
bus_map_resource and make_dev_s use) that was passed up at
bus_setup_intr() time.
I think it should now
be passed up at bus_alloc_resource() time instead, but it would
allow bus drivers to "decorate" a SYS_RES_IRQ request as it goes
up the device tree with properties that the interrupt controller
can then associate with the IRQ cookie it allocates in its own
code.
We used to do this on PPC and MIPS, and the current code still
supports it, but it turned out not to be useful in the end for
IRQs. The hierarchy for IRQs rarely (read: almost never) follows
the bus hierarchy and often is enumerated in a different order. I
have hardware, for example, where the children of a single parent
bus are all wired to different interrupt controllers and sometimes
to a mixture of interrupt controllers. Those controllers are
cascaded in ways that cross the newbus tree laterally and, on some
of them, the parent device from the bus topology has interrupts
handled by its own (bus) children. Trying to make the newbus
parents do something sensible with all of this would be crazy and,
in the case where parents depend on resources provided by their own
children, impossible.
This is all to say that, since you want the interrupts to be
decorated along a path that usually has nothing to do with the
newbus hierarchy, it doesn't add much to add extra features to
resource allocation. ofw_bus_map_intr() is a newbus method to
support this kind of thing but, on all supported platforms, it is
implemented only in nexus and no cases have appeared where anyone
ever wanted anything at the intermediate layers.
Mmm. Another idea that has been bandied about is to create a separate
"plane" in new-bus for an interrupt hierarchy and allow devices to
have "interrupt" parents that are not the same as the "bus" parent.
(Additional planes for power and clocks might also make sense.) The
idea is borrowed from IOKit on Darwin which has multiple planes. The
"bus" plane is always fully populated, but the other planes (Darwin
has one for power for example) can be sparse. ACPI has methods that
effectively describe the power plane on x86.
For some planes the structure would look more like a directed
graph. Devices can have multiple clock parents, e.g. one for the
register interface, and another to drive the external bus.
I can also imagine the case where a device could have multiple
interrupt parents, an MMC/SD controller comes to mind where it may have
an interrupt on a GPIO line to detect the card being inserted, with
another for command completion, etc. In this case one parent would be
the standard interrupt controller, with the other being the GPIO
controller.
Andrew
That's a good point for the generalized system (this already works for
the specific case of interrupts, of course). It's more the resources
that have a non-bus parent than the device. There are also devices with
multiple bus parents, but those are more oddball kinds of things (Apple
made some on-board PCI devices that are also connected by a second
non-PCI path).
-Nathan
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
