From owner-freebsd-arm@freebsd.org Sat Aug 6 16:58:50 2016 Return-Path: Delivered-To: freebsd-arm@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 68AABBB0552 for ; Sat, 6 Aug 2016 16:58:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 2C7EF15EC for ; Sat, 6 Aug 2016 16:58:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id 38so325687074iol.0 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=EFOE6WBiT++c9PfY1LZiDv0vMirflY7A5nrzKJuzbUVR1zTCZF88XCq1hNWZKz8zbU bUH0/XPWfnr5S5g/xr7AcPeoPPeOOFzi7aDlYfgbl5Zoydu2bLT2pZg751FktRWUYQKB P5/0eynjwpcL6s4EOTqwq1xbjQD2BL5uKpknpjwppwVFJAt/A/QPX3dW2LX7OYOJNJiG ibdOIEzLd+YOsreRtI86t9mRCHI8+PRxwJ1rd9T5FZPkqt+duV7zM4PODr5mhpWAWlur wgd5s8ryMUgkx541dQhDGC1+sF8tZr9deINh8EBP9AdIb2J2hsqVNw0brlu5Wi6zZt3t eyTw== X-Gm-Message-State: AEkooutuk3BXSrPZprmzGgjFcYJkIxtigTopn+CLRBEWt4lnQEE5xvylSLfPwtHkQS24VH8pH4/IYzBV2PWJDA== 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-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." 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