| Message ID | 20170609141622.21502-1-o.rempel@pengutronix.de |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel <o.rempel@pengutronix.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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@pengutronix.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. 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.
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@pengutronix.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. > > Please fixme if I miss something. Why is GPIO hogging mechanism not good enough for your purpose? -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@pengutronix.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
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 <o.rempel@pengutronix.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. > > :( 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 <o.rempel@pengutronix.de> --- Documentation/devicetree/bindings/gpio/gpio.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)