From owner-freebsd-arm@freebsd.org Sun Jul 31 14:28:13 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 1676ABA9A61; Sun, 31 Jul 2016 14:28:13 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (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 D50CC15B1; Sun, 31 Jul 2016 14:28:12 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-it0-f45.google.com with SMTP id f6so225997255ith.1; Sun, 31 Jul 2016 07:28:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pj2jQxUWLmt2WZq9vCHqAI5q26TIvxQmEsRZ8HfXsZs=; b=bJdupqX9gVFXsae0OdwLaHcKMqW+ZSGaOVmREyse1wYoiD1Hy35t7kc5DgcLQ+pvIg +pHmcryK5o58MCaw/yf/jgPG49+xoGcmmcnRLHmwhNBpEwfe0UayM6tMfn44LRH3gRmZ 13e2IdCxO3CPR0s/jl6fAn+nnhOAJfVji+OB0+tiT8JYgQPcqv2Xwtdw6XTMAtVJGtai 2qlGJVgA8Nb5ehQBFp3s3fqceutAcjYNPTGjtWDF7unpN1w2UNdOBtUE3w0bB9AmV0KI c8P5ucZigUfJA/JsasIQt16KvvqnPwOwimazHNTIlaX/jxeTV5V0rCwS3iNapvFDSdeu Oo3Q== X-Gm-Message-State: AEkoouvm0PKX7lRp8fI3EVMZcK19DdGcTe7trNjHC6s5qM3973ceg9zp6dqsmV/FDnsLfw== X-Received: by 10.36.110.66 with SMTP id w63mr43498478itc.56.1469974936138; Sun, 31 Jul 2016 07:22:16 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id d71sm11579550ioj.33.2016.07.31.07.22.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jul 2016 07:22:15 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id q83so167181531iod.1; Sun, 31 Jul 2016 07:22:15 -0700 (PDT) X-Received: by 10.107.26.16 with SMTP id a16mr52149745ioa.30.1469974935361; Sun, 31 Jul 2016 07:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.162.75 with HTTP; Sun, 31 Jul 2016 07:22:13 -0700 (PDT) In-Reply-To: <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@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> <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> From: Svatopluk Kraus Date: Sun, 31 Jul 2016 16:22:13 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , "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: Sun, 31 Jul 2016 14:28:13 -0000 Unfortunatelly, I have no time now to read back all this message thread and related ones. Nevertheless, I found time to summarize the main ideas about INTRNG design related to this discussion. Svata ----------------------------------------------------------- INTRNG is designed with three main ideas: (1) An interrupt is identified by one and only unique number. (2) This unique number is assigned only to registered interrupt. (3) The framework does not know any interrupt mapping encoding semantics. A general intr_map_irq() serves to get this unique number for an interrupt mapping. As INTRNG itself does not know any interrupt mapping encoding semantics, it pushes the request to a PIC. Of course, a PIC specification must be provided as arguments to this function. A PIC is specified by either device_t or/and xref (intptr_t). It means that such PIC should be already registered in INTRNG. The idea that INTRNG does not know any interrupt mapping encoding semantics is crucial. It makes INTRNG true general framework. Any interrupt mapping is fully transparent for INTRNG. Any new interrupt mapping semantics can be added without INTRNG concern. That said, centralized interrupt mapping table is no concern for INTRNG as INTRNG works with its interrupt numbers, not with numbers associated with something else. In general, an interrupt mapping table can be established anywhere and clients of this table may use indexes to this table as interrupt specifiers. But if INTRNG bus interface functions are used, a translation to INTRNG interrupt numbers must be done (see paragraph above about intr_map_irq()). In fact, this is a natural case of bridges where interrupts must be remapped. The main reasons why INTRNG does not use a centralized interrupt mapping table instead of an interrupt table are the following: (1) As not only one interrupt mappings can exist for an interrupt in the very same time, it's far more simple, sane, and framework like. One interrupt, one interrupt number, one data associated, no need to know any interrupt mapping semantics. (2) An interrupt mapping is associated with consumer driver and belongs to this driver or some of its parent driver. It's not both sane and newbus like to store an interrupt mapping in some third party - in INTRNG in this case. -----------------------------------------------------------