From owner-freebsd-arm@freebsd.org Tue Jul 26 04:24:55 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 7052EBA56C6 for ; Tue, 26 Jul 2016 04:24:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 1F6A517A9 for ; Tue, 26 Jul 2016 04:24:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id q83so193999718iod.1 for ; Mon, 25 Jul 2016 21:24:55 -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=WMB4q8qs9epdEO2K9XxEQLmKp/HlF7veu4NSwCqgS3U=; b=IAoGPYCX8NxORdQCCFHkalOvVRzQWsyBHLPQ5yU+x3cWuGc8MSZTpvkngNgM/5csN8 jypYrW3VC1bx0ZCftA7mKQlzdLxnwrNnmPtmzK+Eoa/vRq0leTga9Wp8CzvjvBl02/iN faocJAY0Wiqu+tGl+MyCphRW90j30AuWU3I1WMoMg0DrPr/lhnHmvIr8Egp1ZxDZwpfN Buf2N/SD4CNuJpSMsy4uxzO4OVBuyKSSqo+VBisLZxPqE4pJI6tQZLOvzZfLrcGVuh2J I77V8quAkfKFhZx+8ngKofXDpWEymdSGOhhWzYDW+L5JgMpRGBi14/4F86to2jdoh9OP QE4w== 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=WMB4q8qs9epdEO2K9XxEQLmKp/HlF7veu4NSwCqgS3U=; b=jzW4z+iKQr87UUchzGdEe6WMeoVXVEuCQKQjektKqRcpBTNK7Og2wlkGzC1v8GSsGE gtUjEIYEvgW2fI+XrOmdSviAfTFf1Fz7x/QL2tHua95mIbK/9FSjcFbVOOLsTgOKnlEu awuGJcINIoXI9ZK/tfRbI+crvg9ThGjXl14fPpxG61ej81NrWujTS5Pb62WRtPp8U8gX s24VqrS7Kw69u6+PqjSp/9ubvl1N3V5AHFJFf5gAh9W5oEWJfzwCSMpeRthrNwNb6OJF kKlcxQ81IMqRw7WrQ3JpPp7zNNqvxGwFqaGYM2KNUcbWt7O9zHYN6TH21J7zGHsbjT9l 4mQw== X-Gm-Message-State: AEkoousBZb6GFJ3sRw7iCvqt0bQv4remD2gY8AMDhqV1eKkMIDQw3RrVj3Ra17AYIF0U70otzANlrtfSX7mY1w== X-Received: by 10.107.133.93 with SMTP id h90mr23629391iod.16.1469507094415; Mon, 25 Jul 2016 21:24:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Mon, 25 Jul 2016 21:24:53 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@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> <57961549.4020105@FreeBSD.org> From: Warner Losh Date: Mon, 25 Jul 2016 22:24:53 -0600 X-Google-Sender-Auth: kzVHCycSi51vnhDA-XUlIEAYMX0 Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@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: Tue, 26 Jul 2016 04:24:55 -0000 On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn wrote: > > > On 07/25/16 09:32, Warner Losh wrote: >> >> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >> wrote: >>> >>> That wasn't my question. Are these particular device drivers allocating >>> interrupts both on the GPIOs in their "interrupts" property (which are >>> entirely GPIOs in this example) *and* on the GPIOs listed as resources >>> but >>> not listed as interrupts? If they are, then you need a switching >>> mechanism, >>> but that seems pretty unlikely given the names of the non-interrupt GPIOs >>> (they look like outputs). It would also be a somewhat deranged way to set >>> up >>> a device tree -- not that that rules it out or anything. >> >> On Atmel, there's a situation that this covers, I think. >> >> The MCI device has an interrupt in the core: >> >> mmc0: mmc@fffa8000 { >> compatible = "atmel,hsmci"; >> reg = <0xfffa8000 0x600>; >> interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>; >> #address-cells = <1>; >> #size-cells = <0>; >> pinctrl-names = "default"; >> clocks = <&mci0_clk>; >> clock-names = "mci_clk"; >> status = "disabled"; >> }; >> >> and in other places wires in GPIO interrupts for things like card >> eject / insertion. >> >> mmc0: mmc@f0008000 { >> pinctrl-0 = < >> &pinctrl_board_mmc0 >> &pinctrl_mmc0_slot0_clk_cmd_dat0 >> &pinctrl_mmc0_slot0_dat1_3>; >> status = "okay"; >> slot@0 { >> reg = <0>; >> bus-width = <4>; >> cd-gpios = <&pioD 15 >> GPIO_ACTIVE_HIGH>; >> }; >> }; >> >> an interrupt is registered on the cd-gpios pin for when the card changes. >> At >> least in linux, FreeBSD doesn't (yet) implement this, but will someday if >> I get >> back to the armv6 atmel work I started (see at91-cosino.dts for example, >> there's >> others). >> >> I think this is an example of what you are asking about, or did I get >> lost in the >> twisty maze of conversation zigs and zags... >> >> Warner >> > > Where we would run into (minor) problems is if the interrupt parent for the > first mmc0 is the GPIO controller. More generally, if &pioD has interrupt > children specified in some way that is not a > tuple somewhere else in the tree then you would have to have methods to > parse both interrupt specifiers as-obtained-from-interrupts-properties (or > equivalent) and specifiers as-obtained-from-gpio-properties. If the tree > picks one format and sticks with it, you can get away with just the one. > Glancing through the DTS source for this board, that doesn't appear to be > the case and the property formatting is uniform, but I might have missed > something in one of the many #includes. Interrupts and GPIO specifiers are different in subtle ways. The interrupt parent for mmc0 is an AIC, which is also the ultimate parent of the GPIO controller. But the properties for the GPIO pins that act as interrupts and the interrupt specifiers are different. > As a general point, GPIO weirdness would be easy enough case to handle if it > did come up (add some mapping method, as above) that I think we shouldn't > worry too much about it from an architectural point of view. If a board > appears that is set up this way, we can roll with the punches at that point > and add whatever small amount of shim code that is required. It would be > annoyance, sure, but not a real complication. I suspect that either I don't understand the issue, or we'll have such boards very quickly. The Atmel design is fairly clean in comparison to other franken-horrors I've seen... Warner