[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170615055632.qjtyf6kiqdam3mho@pengutronix.de>
Date: Thu, 15 Jun 2017 07:56:32 +0200
From: Oleksij Rempel <ore@...gutronix.de>
To: Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexandre Courbot <gnurou@...il.com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Oleksij Rempel <o.rempel@...gutronix.de>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
barebox@...ts.infradead.org
Subject: Re: [PATCH v1 1/1] gpio: of: provide option generic property for
initial line states
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 <o.rempel@...gutronix.de> 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.
:(
> > 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.
> >
> > 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.
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>;
};
Boot loader will configure it as needed, an linux will do nothing with
it so it can be used over /dev/gpio interface.
> --
> With best wishes,
> Vladimir
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists