Date: Fri, 29 Jul 2016 23:55:08 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Svatopluk Kraus <skra@freebsd.org> Cc: Nathan Whitehorn <nwhitehorn@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Michal Meloun <mmel@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: INTRNG (Was: svn commit: r301453....) Message-ID: <CAJ-Vmon13F_E=BeeOVw6__3UGsvxM-F0iSgPb=5pTpFKui=LXQ@mail.gmail.com> In-Reply-To: <CAFHCsPXON9xQdLou=0ZXEieMVenL-Og2cpWYucSgD3fTp63%2BTw@mail.gmail.com> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <f82018ee-51e7-60fa-2682-f0ef307a52b5@freebsd.org> <57961549.4020105@FreeBSD.org> <e2cace17-0924-2084-5fcf-626f87e41cc3@freebsd.org> <CANCZdfr%2BZ4XxXRY0yMiWXwp=8iKq54y3uJ9-OfAOdfxAs1qdtw@mail.gmail.com> <f94bfd25-fabf-efc3-55c9-cfdfd9e4d6e6@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> <CAFHCsPXON9xQdLou=0ZXEieMVenL-Og2cpWYucSgD3fTp63%2BTw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 July 2016 at 15:16, Svatopluk Kraus <skra@freebsd.org> wrote: > Well, I'm online again, unfortanately, I'm quite busy, so just quick > response for now to the formal ask for the reversion. > > On Fri, Jul 29, 2016 at 4:41 PM, Nathan Whitehorn > <nwhitehorn@freebsd.org> wrote: >> > > [snip] > >> >> So here is where I am right now: >> - The perceived advantage of the new API seems to be that the mapping >> information (interrupt parent, etc.) ends up in a struct resource instead of >> in a centralized mapping table > > It's more than that. The change has made INTRNG framework not > dependent on OFW(FDT) stuff. So after next r301543, the framework is > clean of all additions related to various buses. It was something I > wanted to do before FreeBSD-11 release, once when adrian@ moved INTRNG > to sys/kern. The framework is used by arm, arm64 and mips now, so from > my point of view, it was quite important. The way how it was done is > not perfect and may be changed in the future. However, it does not > break anything, does not change old functionality, and only few bus > drivers were modified slightly. It was also only way which I and > Michal have agreed on considering current kernel code. > > >> - Additionally, it gives you a better shot at having the PIC online before >> the PIC's interrupts are parsed (which is not required, but nice). > > For me, it's just correct design. Please, not all world is about OFW. Hi, Right, but the world does include open firmware, and Nathan/Justin have a lot of experience over on the powerpc side with all the crazy variants on interrupt enumeration and handling there. I think you and Nathan are sort of on the same page, but sort of not on the same page, and Nathan is trying to ensure things don't become more complicated moving forward. I really do suggest this stuff get written down and thought about a little more, and not just in the context of the ARM style GIC/PIC+GPIO interrupt setups that people are writing code for. Don't get me wrong, I'm glad it's happening, but there are more consumers involved than just ARM. :) So, are you/Michal willing to describe some of the ARM interrupt/platform hilarity on his wiki page (https://wiki.freebsd.org/Complicated_Interrupts ) so everyone can be on the same page (heh!) ? Right now there's a lot of information floating around in emails but it's hard to pull out exactly what's going on unless you're knee deep in it all working on that platform. I'm trying to figure it out too for the MIPS + GPIO interrupt stuff that people are now doing with the QCA MIPS hardware and I'd like to make sure I know what's required for the QCA ARM (Dakota/IPQ8019) hardware. Thanks! -adrian -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon13F_E=BeeOVw6__3UGsvxM-F0iSgPb=5pTpFKui=LXQ>