svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys

[Nathan Whitehorn]

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 <mmel at 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