Date: Sun, 18 Jan 2015 16:03:23 -0800 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-arm@freebsd.org Subject: Re: interrupt framework Message-ID: <54BC49CB.4020504@freebsd.org> In-Reply-To: <20150118203021.3ecac737@bender.lan> References: <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com> <54B7EB67.6010702@freebsd.org> <20150118203021.3ecac737@bender.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/18/15 12:30, Andrew Turner wrote: > On Thu, 15 Jan 2015 08:31:35 -0800 > Nathan Whitehorn <nwhitehorn@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54BC49CB.4020504>