Date: Sat, 6 Aug 2016 10:58:48 -0600 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Michal Meloun <mmel@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Svatopluk Kraus <skra@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: INTRNG (Was: svn commit: r301453....) Message-ID: <CANCZdfreALoF1UnqY7h4BXCbRLZ_7z6FNL6Gmvh4hrVKNZ-g4w@mail.gmail.com> In-Reply-To: <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <CANCZdfpz=z3gc3pyb_Qssa3vGJSnPv_r6J-SWDPPpE9zPYB9=w@mail.gmail.com> <ab44ddb1-515b-94ac-6b12-673b7c53d658@freebsd.org> <57976867.6080705@FreeBSD.org> <f2edac8f-2859-cd98-754e-881e2b2d1e63@freebsd.org> <5798E104.5020104@FreeBSD.org> <a5d43044-1733-6cc7-2e99-e85b60b0fcf3@freebsd.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <eb603349-eb88-866d-7a26-9e026518fd39@freebsd.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <cefdfaab-a95f-2a92-89bd-3d0cef2a75ab@freebsd.org> <57A09F34.4050400@FreeBSD.org> <ad1e6337-468e-f35d-7454-444a561cb103@freebsd.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 6, 2016 at 10:44 AM, Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: > Fair enough! I don't think we need that for, e.g., GPIOs (see cases 1-2 > above), just for bus enumeration schemes (ACPI, OFW are probably the only > ones) that usually require a ton of this kind of thing anyway. But, > fundamentally, it doesn't matter. There are three important things from my > end: > 1. That it is possible to, at bus enumeration time, permanently assign an > IRQ to an interrupt specifier from OFW/ACPI. > 2. That that assignment not depend on having the PIC attached yet. > 3. That the implementation details of that mechanism be reasonably > abstracted so that they can change later or vary platform to platform. > > Whether mapping tables are in some central place (subr_intr.c) or in the > parent bus, how the PIC API works, whether they are stored in that table in > the form of a union or in different tables, doesn't matter for those three > at all. And, with a constant API (3) we can even change our minds later > without a lot of hassle. First, I hate mapping tables at the nexus, unless they are created dynamically at run time. There's too much variation between boards, SoCs, etc to have that code live in the nexus otherwise. They simply don't scale. This board has interrupts 1-16 wired this way, but that board didn't do that and has an external PIC. This SoC based on Cortext A<whatever> uses the GPIC, while that one based on the same Cortext A<whatever> chose to use Atmel's PIC. Perhaps I'm misunderstanding something here as to what is meant by a table though. Next, In your list there's another dependency that's implicit but maybe not called out. You can have PICs that cascade into other PICs, or GPIO controllers that need to enable external PIC-like things before they can route interrupts from things that are downstream (interrupt wise) from them. Maybe I'm just hung up on the phrase "the PIC" and it really means "whatever complex thing or things handles getting the interrupt routed to the CPU." I don't see this design so much on basic eval boards, but do see it in more complex boards that control complicated things. Generally, though, I like the direction things are going. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfreALoF1UnqY7h4BXCbRLZ_7z6FNL6Gmvh4hrVKNZ-g4w>