Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752222Ab2KEMJY (ORCPT ); Mon, 5 Nov 2012 07:09:24 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:33088 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750985Ab2KEMJW (ORCPT ); Mon, 5 Nov 2012 07:09:22 -0500 MIME-Version: 1.0 In-Reply-To: <7471321.6NJDeDGfYW@percival> References: <38620644.IyR5R8rjKP@percival> <7471321.6NJDeDGfYW@percival> Date: Mon, 5 Nov 2012 13:09:20 +0100 Message-ID: Subject: Re: How about a gpio_get(device *, char *) function? From: Linus Walleij To: Alex Courbot Cc: Grant Likely , "devicetree-discuss@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3534 Lines: 78 On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot wrote: > Interesting. I see you already gave the whole thing a thought. What I don't > understand however is what is so wrong with the current GPIO numberspace that > you want to replace it? Whether we use simple integers or blind pointers, the > adressable space will basically remain the same. GPIO numbers can actually be > considered as handles, and actually I would not mind typedef'ing "int" to a > GPIO handle type in order to add more opacity to the framework. So the basic problem is scalability and multiplatform support. Currently we have a global "roof" on GPIO numbers, ARCH_NR_GPIOS, which is helpfully set to 256 in include/asm-generic/gpio.h. In the embedded case "ARCH" is a particular board for a particular SoC so this number is actually roof:ed for some arbitrary combination of SoC + electronics, at compile time, for that very machine. So what happens when we try to achieve multiplatform support in the ARM tree (same for others, I expect ACPI etc to run into the same problem) is that this has to be set to some arbitrarily high value so that all GPIOs will fit, and they are not sparse, so if you're just using GPIOs 0 .. 15 and 199935..200000 you will need to reserve 200000 * sizeof(int) bytes. So to avoid this, arch maintainers try with different clever macros to pack the GPIO number assignments per board downward to begin at 0 and keep the array at minimum size, and do not dynamically grab GPIO numbers as they like. Contrast this to IRQs which are in the CONFIG_SPARSE_IRQ case stored in a radix tree and IRQs can be sparse like this without wasting much memory. So IRQdomains can for example just grab a number of free IRQ descriptors and the actual numbers returned do not matter. Using static number assignments also has the side effect that developers will just int mygpio = 42; directly in the code to cut corners and invites such laziness instead of allocating and propagating resources. With abstract handles this does not happen. So moving forward we need a dynamic, radix tree of sparse GPIOs, and we need to follow the design pattern of IRQ descriptors to keep the kernel consistent, for example pinctrl does this with pins - these are sparse and dynamically allocated. They do not have integer numbers other than locally for a particular pin controller. > Also the current DT bindings will likely continue to require the legacy API > anyway, so I am not sure we can make it go away. We can make any DT business go away as long as all DTS files are maintained in the kernel and especially if their structure is not future-proof. The "DT contract" to make bindings stable and everlasting is being broken every day as things are right now. Not that I know the DT stuff by heart, but if the way we're doing GPIO in DT is requiring the OS to use a certain type of static array implementation it must be wrong since DT is supposed to be OS-neutral. > My initial thought was to build something on top of the existing scheme to > address my immediate needs - what you are talking about is much more scary. :) > Could you elaborate on your motivations for such a radical direction? See above. I suspect Grant have similar thoughts, but let's see... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/