Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbdFOJsk (ORCPT ); Thu, 15 Jun 2017 05:48:40 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:33404 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbdFOJsi (ORCPT ); Thu, 15 Jun 2017 05:48:38 -0400 Subject: Re: [PATCH v1 1/1] gpio: of: provide option generic property for initial line states To: Oleksij Rempel References: <20170609141622.21502-1-o.rempel@pengutronix.de> <20170611061919.jsbc7x67ut4segj5@pengutronix.de> <2432df7e-5d20-42c9-ddc0-044c2ca5ce2b@mentor.com> <20170615055632.qjtyf6kiqdam3mho@pengutronix.de> CC: Rob Herring , Mark Rutland , Alexandre Courbot , "linux-gpio@vger.kernel.org" , Linus Walleij , "linux-kernel@vger.kernel.org" , Oleksij Rempel , "devicetree@vger.kernel.org" , "kernel@pengutronix.de" , From: Vladimir Zapolskiy Message-ID: <55bfb5e4-a6ff-89a1-3807-e4f4e4b0cef8@mentor.com> Date: Thu, 15 Jun 2017 12:48:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20170615055632.qjtyf6kiqdam3mho@pengutronix.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.87] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3461 Lines: 99 Hi Oleksij, On 06/15/2017 08:56 AM, Oleksij Rempel wrote: > Hi Vladimir, > > On Sun, Jun 11, 2017 at 10:57:18PM +0300, Vladimir Zapolskiy wrote: >> Hi Oleksij, >> >> On 06/11/2017 09:19 AM, Oleksij Rempel wrote: >>> Hi Rob, >>> >>> On Fri, Jun 09, 2017 at 10:41:30AM -0500, Rob Herring wrote: >>>> On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel wrote: >>>>> This property is needed for barebox or may be other bootloaders >>>>> to set proper gpio configuration as early as possible. >>>>> >>>>> This example is mainly based on "lines-initial-states" property >>>>> from this binding documentation: >>>>> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt >>>> >>>> Don't we have a binding for this already based on gpio-hogs. >>> >>> Markus Pargmann was working on this topic before and suddenly was not >>> able to finish it. >> >> that's fine, but the proposed extension is supposedly not wanted. > > :( No worries, we're in the discussion and 'supposedly' was a meaningful word :) >>> I found only some not finished discussions and no code or documentation >>> in linux kernel upstream. >>> >>> So far, I was able to find fallowing patches and discussions: >>> patch 23.08.2015, last comment 11.05.2017: >>> https://patchwork.kernel.org/patch/7096721/ >>> >>> patch 23.02.2016, last comment 09.03.2016: >>> https://patchwork.ozlabs.org/patch/586743/ >>> >>> Since there was objections about node-like design for gpio-initval, I >>> provided an array property, which is similar to initval properties already used >>> for different other device nodes. For example: >>> >>> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >>> qcom,ath10k-calibration-data >>> >>> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt >>> lines-initial-states >> >> It'd rather be better to fix the drivers and remove the properties >> from these found device tree binding descriptions. > > no sure if it is possible. WiFi calibration data is kind of initval too. Sorry, I have no idea about the ath10k calibration data and its connection to the GPIO framework. >>> >>> Please fixme if I miss something. >> >> Why is GPIO hogging mechanism not good enough for your purpose? > > Becouse it should not permanently hog a gpio. The "Hogging" should be > released as soon as some driver will request it. > > Right now, if I define gpio-hog, boot loader will configure it and start > linux. But linux will never let it free. > > If you have other suggestions which fit to this use case, please tell > me. I assume, right now I'm just blind. Ok, I'll meditate on it. > Other way, I can imagine is to create real device nodes which use this > gpios. Compatible for this devices will be like this: > some_gpio_holder: gpio@0 { > compatible = "gpio-for-userspace"; > gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>; > }; Generally it might be a good option, because if GPIOs are essentially needed to be preset, I can conclude there are some ICs to which these GPIOs are connected, thus drivers of these ICs can become GPIO consumers and get a proper description in a board DTB. > > Boot loader will configure it as needed, an linux will do nothing with > it so it can be used over /dev/gpio interface. As I read it from Documentation/gpio/sysfs.txt generic interface(s) to control GPIOs is a last resort, it is not clear if you want a new feature for all possible consumers or just userspace consumers. -- With best wishes, Vladimir