interrupt framework

[Nathan Whitehorn]

On 01/18/15 12:30, Andrew Turner wrote:
> On Thu, 15 Jan 2015 08:31:35 -0800
> Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
>> On 01/15/15 05:51, Svatopluk Kraus wrote:
> ...
>>> It's a controller responsibility to save an ISRC associated with
>>> cells. An ISRC is transparent for any controller. However, an
>>> controller can set/get its data to/from an ISRC. Further, an
>>> controller should set a name to an ISRC according to internal
>>> representation of associated interrupt.
>> I'm assuming you are referring to arm_describe_irq? I had three
>> comments on that:
>> 1. Can you please make it part of the same API as ofw_bus_map_irq()
>> rather than an out-of-band thing? This will let other platforms use
>> it.
> It should also not be ofw/fdt specific as it will be needed on
> platforms that don't use these, e.g. I expect there to be an option on
> arm64 to use ACPI so it could be possible to have a kernel without
> either of these enabled.

Right, this was my point #2. I'd forgotten it is immediately necessary 
on ARM with ACPI as an option.

> Another problem is most drivers will already be using
> resource_list_print_type so may need to be modified to replace a call
> to this with a call to some new function. I have a proof of concept
> patch at [1] to instead rework how resource_list_print_type works by
> allowing us to change how various resource types are printed. It does
> this by having a function to register a callback to print the resource
> type. If no callback has been registered it will use the default.

I think that's a good idea.

> In the short term I expect we could import the interrupt change without
> changing how we print interupts. The values in dmesg may not line up
> with the actual interrupt, but this shouldn't hold back testing.

This is what we have been doing on PowerPC for years now. It hasn't 
caused more than minor annoyance.
-Nathan

> Andrew
>
> [1] https://people.freebsd.org/~andrew/rl_print_cb.diff
>