From owner-freebsd-arm@freebsd.org Sun Jul 24 22:38:18 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 15713BA3302 for ; Sun, 24 Jul 2016 22:38:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E68B61364; Sun, 24 Jul 2016 22:38:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6OMcEM7028658 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2016 15:38:15 -0700 Subject: Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys To: Michal Meloun , Svatopluk Kraus , freebsd-arm@freebsd.org 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> From: Nathan Whitehorn Message-ID: Date: Sun, 24 Jul 2016 15:38:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57950005.6070403@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbxsU7wVoV5X8eeAOws7AobMQTIvl5L1AOcvKlpYcOxYvRX68nKtgM1SIKJpVwALfEFgARWTRjj7AKxny7tDHC4Q9NP01USJOE= X-Sonic-ID: C;5m4yT+9R5hGDPZNwxPCmMQ== M;9kJ2T+9R5hGDPZNwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 24 Jul 2016 22:38:18 -0000 On 07/24/16 10:51, Michal Meloun wrote: [snip] >>> >>>> >>>>> For this reason we makes domain key composite, in our model, the >>>>> domain key consist of "domain key type" >>>>> and "domain key value". This composite key guarantees uniqueness >>>>> and it also allows to select proper parser for byte string. >>>> >>>> Yes, but this solves what is a nonexistant problem by making the >>>> system substantially less flexible and more invasive. Which is not >>>> a good tradeoff. >>>> >>> I think that existence of problem is confirmed in the above example . >>> Quote from previous paragraph: >>> "We could solve this in a number of ways, ... , or adding another >>> value (domain type, for example)." >>> What can I say more ... >> >> Except that the example you gave *is not an example* of the problem >> you are describing. You would only end up with a problem if: >> 1) You had interrupts in a GPIO property rather than in an interrupts >> property (or equivalent). >> 2) *And* you had interrupts on GPIOs in an interrupts property (or >> equivalent) >> 3) *and* those are encoded differently >> 4) *and* the different encodings use the same number of cells >> 5) *and* are not otherwise distinguishable >> >> Does that ever actually happen, in the real world, on any device >> tree? You could imagine any kind of messed up thing you want, but we >> shouldn't structure APIs around them, especially given that the >> current alternative you are proposing has real, concrete problems on >> real hardware that actually exists. >> > Allow me to respond to this issue only. I think that this main issue, > everything else looks resolvable for me (or, in worst case, can be > converted to MD code). > > from linux/arch/arm/boot/dts/am335x-evm.dts (it's first file that I'm > searched) > > ---------------------------------------------------------------------------------------------------------------------------- > &gpmc { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&nandflash_pins_s0>; > ranges = <0 0 0x08000000 0x1000000>; /* CS0: 16MB for NAND */ > nand@0,0 { > compatible = "ti,omap2-nand"; > reg = <0 0 4>; /* CS0, offset 0, IO size 4 */ > interrupt-parent = <&gpmc>; > interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ > <1 IRQ_TYPE_NONE>; /* termcount */ > rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ > ---------------------------------------------------------------------------------------------------------------------------- > so we have > rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ > and > interrupt-parent = <&gpmc>; > interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ > > > --- or --- > from linux/arch/arm/boot/dts/exynos5420-peach-pit.dts > > max98090: codec@10 { > compatible = "maxim,max98090"; > reg = <0x10>; > interrupts = <2 0>; > interrupt-parent = <&gpx0>; > pinctrl-names = "default"; > and > sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>; > > also, in this case, first cell in 'interrupts' property have different > meaning that second cell in 'sleep-gpio'. > (on exynos, not all gpios supports interrrupts) > > > In general, binding for 'interrupts ' and '-gpios ' are > different, but can have same size . Thanks so much for the concrete example! This is very helpful. Three questions: 1. Are the drivers for these devices actually taking interrupts on the lines defined in the *-gpios property? It seems weird to me that there would be interrupts on GPIOs and, simultaneously, implicit interrupts on other GPIOs. It looks like the things on the *-gpios properties are things you set rather than things you would request an interrupt on (sleep for the second case, a wait pin in the first). 2. What is the different meaning? I assumed the second cell in both cases is the GPIO pin number, because anything else would be crazy. 3. What on earth is IRQ_TYPE_NONE? That's an OpenPIC flag that just disables the interrupt entirely. Why would you want to configure things that way? (#1 is the only one that really matters here; the rest are personal curiosity) If the answer to (1) is "yes", there would be a good case for adding something like a ofw_bus_map_gpio_as_intr() or the like that takes the same arguments as ofw_bus_map_intr() and propagates them to the control in some way but with a flag. It's an easy extension and this is the reason the function has "ofw" in the name. My one qualm about that is that there is no guarantee that a GPIO controller can actually provide interrupts on a random GPIO (nor is it clear that that is actually what is wanted here). That qualm applies to both APIs, of course, and I still don't see a rationale for throwing away the existing code even if (1) is true. I've changed the mailing list here since the SVN list really isn't the best place. For people who want context and are seeing this for the first time, please see the other email I just sent. -Nathan