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:53, Andrew Turner wrote:
> On Fri, 22 Jul 2016 13:19:32 -0700
> John Baldwin <jhb at 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 <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.
> 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