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
Signed-off-by: Oleksij Rempel <[email protected]>
---
Documentation/devicetree/bindings/gpio/gpio.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 84ede036f73d..60f8e8d8ab32 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -181,6 +181,26 @@ gpio-controller@00000000 {
"poweroff", "reset";
}
+Optionally, a GPIO controller may have a "gpio-lines-initial-states" property.
+This is an array of values that specifies the initial state of each line. When
+a value is set to one, the corresponding line will be initialized to the input
+(pulled-up) state. When the values is set to two, the line will be initialized
+the low-level output state. If values is set to zero the line will be
+initialized to the input state.
+If the property is not specified no specific configuration will be set. Driver
+should reuse HW configuration provided by bootloader or other system.
+
+Example:
+
+gpio-controller@00000000 {
+ compatible = "foo";
+ reg = <0x00000000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <9>;
+ gpio-lines-initial-states = <0>, <1>, <2>, <0>, <0>, <2>, <2>, <1>, <1>;
+}
+
The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
providing automatic GPIO request and configuration as part of the
gpio-controller's driver probe function.
--
2.11.0
On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel <[email protected]> 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.
Rob
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 <[email protected]> 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.
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
Please fixme if I miss something.
--
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 |
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 <[email protected]> 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.
>
> Please fixme if I miss something.
Why is GPIO hogging mechanism not good enough for your purpose?
--
With best wishes,
Vladimir
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 <[email protected]> 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 |
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 <[email protected]> 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