Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752066AbbKKEDe (ORCPT ); Tue, 10 Nov 2015 23:03:34 -0500 Received: from lkcl.net ([217.147.94.29]:56654 "EHLO lkcl.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751285AbbKKEDd (ORCPT ); Tue, 10 Nov 2015 23:03:33 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 11 Nov 2015 04:03:19 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: devicetree live reconfigureable hardware (eoma68) From: Luke Kenneth Casson Leighton To: Pantelis Antoniou Cc: Linux Kernel Mailing List , Grant Likely Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3813 Lines: 83 hi pantelis, don't freak out, but the best introduction i can think of to what occurred to me is, "arg fek that is an ecumenical matter! [1]". *deep breath* - i can forsee a need for parameterisation to be added to the proposed connector objects in some fashion. justification / explanation follows. if you recall, i mentioned previously the idea of having dtsi fragments which, in effect, allow an interface instance to select "pin 1 of interface is to be a GPIO" by some form of naming convention [aka connector objects] or "pins 2, 3, 4 and 5 are to be SPI NSS, CLK, MOSI and MISO respectively". the problem is, that's nowhere near enough. for example, i have a board where one of the pins is a power-up for the 3.3v regulator. if that regulator isn't enabled, USB is offline, the SD/MMC is offline - all of which saves power, and also, importantly, when things are "floating" [i.e. the CPU card itself is powered down], the 3.3v regulator is *also* powered down. this is important because the board is battery-operated. i mention this because someone might suggest, "but why don't you just pull up that GPIO pin to HIGH with a resistor?" - answer, "because that would drain the battery". so that fragmentation previously mentioned - where SD/MMC "fragments" have to be created, one for SD/MMC in 1-pin mode, one for SD/MMC in 2-pin mode, one for 4-pin mode, and so on... that now applies for GPIO *as well*. in other words, a .dtsi file [or entry, or connector object] would need to be created which specifies: "pin 1 on the interface is a GPIO, and it's an input" "pin 1 on the interface is a GPIO, and it's an output, defaulting to push-push type, HIGH" .... you can see where this is going. each of those required states is near-identical. we could even name them [i'm assuming that names may include brackets]: "pin1_is_gpio(input,0,0)" "pin1_is_gpio(output,0,1)" ... which very much looks like functions, with parameters. and if it looks like parameters, and smells like parameters, where the definitions of those connector objects are near-identical except for a one-to-one correspondance between the parameters in the name and the purpose _behind_ those parameters, then, logically and undeniably, it makes sense to actually *make* them parameters [and, by inference, to have support for macros / functions in devicetree]. the advantage here would then be that things like the GPIO that's to be used as a pin-select on SD/MMC becomes.... a parameter. much as i am reluctant to suggest it, it has to be voiced: the next logical extension would be some form of switch statement / conditional selection, based on a parameter's value, allowing decisions to be made as to whether SPI should be 3-wire or 4-wire, whether SD/MMC should be 1, 2, 4 bus width or SPI-mode compatible, and so on. the alternative is this dog's dinner set of near-identical pre-defined hard-coded set of all possible entries that could ever possibly exist. which, now that i think about it, _could_ be auto-generated using some scripted programming / macro language e.g. python, perl, bash or m4, "gcc -E" and so on. i believe you'll then find that there are significant benefits to the concept of macros/functions as part of devicetree: i think you'll find that there will be some drastic simplification and reduction in the size of some of the dts and dtsi files. looking at the sunxi files for the very first time over the past 24 hours, i notice an alarming amount of duplication of near-identical segments. l. [1] https://www.youtube.com/watch?v=2TQuacxEjAU -- 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/