On 07/22/16 13:19, John Baldwin 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.
That's basically what the virtual IRQ code does: it implements a
separate IRQ "plane" that is lazily interconnected during bus attachment
and then strongly interconnected at configure_final() (i.e. it panics at
that point if the topology hasn't converged yet). A generalized version
of this concept would be useful for a number of other resource types
(power, clocks, GPIOs, etc.) and I would be very happy to see it as a
standard part of the OS.
-Nathan
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
