svn commit: r301451 - in head/sys: kern sys

[Svatopluk Kraus]

On Mon, Jun 6, 2016 at 8:47 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Sunday, June 05, 2016 04:07:57 PM Svatopluk Kraus wrote:
>> Author: skra
>> Date: Sun Jun  5 16:07:57 2016
>> New Revision: 301451
>> URL: https://svnweb.freebsd.org/changeset/base/301451
>>
>> Log:
>>   (1) Add a new bus method to get a mapping data for an interrupt.
>>
>>   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
>
> Does anything need to query this data besides the "nexus" or similar
> driver at the top of bus_alloc_resource()?  If so, I'd much rather do
> this by having an optional args structure passed to bus_alloc_resource
> that is extensible ala make_dev_s() and bus_map_resource().  Previously
> I had mentioned passing this as part of bus_setup_intr() rather than
> bus_alloc_resource(), but it would actually work better for ACPI if
> we did it for bus_alloc_resource() instead.
>
> I guess my question is do you need access to this beyond the lifetime
> of the call to bus_alloc_resource().  On x86 for example the state that
> would needed to be passed up from ACPI (currently via bus_config_intr())
> is stored in the interrupt source structure, so it doesn't need to be
> attached to the resource directly, it just needs to be passed up with it
> so it can be saved in the interrupt source structure.
>
> --
> John Baldwin


INTRNG was designed with the idea that a description of an interrupt
belongs to a device, not to an interrupt itself. The very same
interrupt may be used by more devices and each device should keep own
description for this interrupt as these descriptions may differ - one
can be GPIO like, another FDT like - one can demand binding to cpu0,
another to cpu3 - and so on. In FDT case, it's regular as there are
configurations for all possible devices in FDT blob, and it may be
runtime choice which device will be used and you may even alternate
these devices (meaning those which use the same interrupt). In the
interrupt source structure (in a controller specific part) is then
saved the info how an interrupt is really setup, and it's done in a
controller native form. For example, when an interrupt is shared, two
devices can be attached, both can allocate the same interrupt, but
their configurations may differ. They can be setup at the same time,
but also in rotation.

Now, to answer your question. The interrupt mapping data is only
needed in two situation for now. First, when a global scope interrupt
number is looked up. It may be done during bus_alloc_resource() call.
Second, when an interrupt is setup during bus_setup_intr(). When this
data is saved in struct resource, it belongs to a device and can be
used repeatedly during lifetime of this struct. And there is no need
to modify any driver.

Look also at r301539. An interrupt mapping data is saved in
gpio_alloc_intr_resource(), so bus_setup_intr() can be used as is.

Svatopluk Kraus