Date: Tue, 15 Apr 2014 08:11:57 -0600 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: [RFC] Refactored interrupt handling on ARM Message-ID: <ACD52C94-A44A-42FD-8016-61B0B21B12D9@bsdimp.com> In-Reply-To: <534CC733.7010009@freebsd.org> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <f2bebfa812ecb70f423b6be4779b217b@uj.edu.pl> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 14, 2014, at 11:44 PM, Nathan Whitehorn <nwhitehorn@freebsd.org> = wrote: >=20 > On 04/14/14 15:44, Jakub Klama wrote: >> On Mon, 14 Apr 2014 15:00:10 -0700, Nathan Whitehorn wrote: >>> I had deliberately made it private with the last round of interrupt >>> changes. The idea was to rely completely on newbus for interrupt >>> mapping. Having a public interface allows code to bypass the bus >>> hierarchy, which usually isn't a good thing. This ended up happening >>> all over the place on PowerPC, for example. This made a lot of = drivers >>> less MI than they should have been and took a lot of time to get rid >>> of. >>=20 >> Agree. In fact, we can completely remove FDT_MAP_IRQ macro, as well = as >> FDT_INTR_MAX. >>=20 >> Jakub >>=20 >=20 > Great! Very nice work with all of this, by the way. It's a thorny = problem and I'm glad to see it being solved. This is looking nice on the surface. I=92ve done a small portion of this = sort of work for the Atmel port, so I=92ll see how well this can be = extended to work there. Unlike the gic device, there=92s 3 or 4 pio = controllers that act as interrupt handlers, plus the need to wire up = pins relatively early... I=92d clean up the name =91intrng.c=92 though, since ng things tend to = become dated=85 ARM_INTRNG also suffers from this naming flaw. Is there = any reason not to have it on all the time? Also, the ARM_INTRNG ifdef is = inconsistently applied. Looking at the FDT, it appears that the interrupt numbers are hard coded = for things that appear to be connected to GPIOs. This hard coding (and = changes to reflect differences in mapping) is really bad. Linux = specifies the GPIO more directly (though each SoC is different in the = details). I haven=92t looked at LPC (where I noticed the change) on = Linux to see if these changes bring us closer to being able to use the = stock FDT for that platform. Do these changes help with that? While I = appreciate the aesthetic appeal of having purely an interrupt number and = PIC (interrupt parent), I=92m not sure that will work everywhere. dosoftints() does nothing, is that on purpose? 255 is too few interrupts to have. We need easily twice that for Atmel. = And chance we can remove NIRQ as well? Finally, I=92m not sure what the change to kern_intr.c is supposed to = accomplish. It seems weird to me. Can you explain it? I=92d think that = would have a bad effect on other platforms. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ACD52C94-A44A-42FD-8016-61B0B21B12D9>