From owner-freebsd-arch@freebsd.org Sat Aug 6 16:58:50 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A513BB0553 for ; Sat, 6 Aug 2016 16:58:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C88315EE for ; Sat, 6 Aug 2016 16:58:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id q83so326227493iod.1 for ; Sat, 06 Aug 2016 09:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eGdiIVVZoY7D8RF1q9koNMFhBK16ze1HkKAN9Jb9Ids=; b=V0xo72+Kk8pa6zzvnvabxqUozxITJxxkVnx+3lnbZqTEigCuCrTOmFUIfMhWkyOulp klAl3v3NcQZBexfQJz0mjJ3BBX1cwFcHGaIHASdHLVMHr4XWM8G7E1gcZBOA/LWfaoL/ 1/s2bcn8UOZvMjMKvUm+6lPXts47wtINXD1WGKhwKbO/6h+umoRJE79dr8gkKo93Se+M 93RmdK5CTuPqnD/0vew1jTXT38MEFzDq0b+is6JggXqMpe8yUMvUxLwerW10RAMygfil MnB58NXfU3NJ0njKDLh/zWA07kbjJtHiY0rLHNTaF2ONhrREWAnGQRFfnsDWzBsDid6K fSJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eGdiIVVZoY7D8RF1q9koNMFhBK16ze1HkKAN9Jb9Ids=; b=DL+hGebEXzV65kWwkJcZ8jMOoyJ1b2uWoByt5qI8hW4AF2/HY/jQltVl/b45ge8n06 E/c/HQKtxCVhz91XqF51ZFZdXX9a5znhM0w+f1FeC1XupmrI6y2mbU7d7cc6xgb2hwj5 DZV0aQvls3aaWw64o6pg4wjm4tU0Vz7aZLDoKb63pjesD6Q/XVqr0MwHM1msQlM8ELPo b8AbKXckks/v/yzuHk1Hv/RwXJDYGkSLROXtAJ94+FAg6C/UYijpgTrA8Y7PWtEpWSNM EdHzFhs7vWV+1O+movzM7ItNJLfcJmI78gEvVx7VCDQTvmydUNxl2Q+tmScL48OHqybl AXow== X-Gm-Message-State: AEkoouvIXR+QD76cr/KaRMpz4ErJeQQwxKHMLmzkVU1EOEOq4z8SAG34ypejhCNWE6I+7I81/DPB6CEMM5Ssbg== X-Received: by 10.107.9.39 with SMTP id j39mr84327957ioi.73.1470502729575; Sat, 06 Aug 2016 09:58:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.105 with HTTP; Sat, 6 Aug 2016 09:58:48 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@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> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> From: Warner Losh Date: Sat, 6 Aug 2016 10:58:48 -0600 X-Google-Sender-Auth: _0BEYsZVKtprYz0QGNWpalXtUEk Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 16:58:50 -0000 On Sat, Aug 6, 2016 at 10:44 AM, Nathan Whitehorn 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 uses the GPIC, while that one based on the same Cortext A 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