Re: Accessing GPIOs from userspace using recent kernels
Hello Tony, On Fri, May 23, 2014 at 5:11 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [140523 04:36]: On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote: The current call chain seems to be: gpiod_export() -- gpiod_request() -- omap_gpio_request(). Looking at other GPIO drivers, it seems like omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be useful if someone who knows about OMAP4/gpio/pinctrl could take a look at this. I looked briefly at adding pinctrl back-end commands to the OMAP GPIO driver. That is to make all GPIO operations fall through to the pinctrl-single driver as Linus suggested before. The changes in the GPIO driver are quite trivial, here is a RFC patch [0] that has only build tested but I think is useful to at least discuss this. Now, in order to make that patch to actually work someone has to register the chip GPIO range to pin controller mapping with gpiochip_add_pin_range() or something similar to make pinctrl_get_device_gpio_range() to succeed. The pinctrl-single driver has a pinctrl-single,gpio-range property that can be used to define a GPIO range to be registered. But the problem is as you said that since there are two different hw blocks for pin muxing and GPIO control, the pins that can be multiplexed as GPIO are scattered all over the padconf registers address space. So there isn't an easy way to specify the mapping and we will have to add an entry on pinctrl-single,gpio-range for every single GPIO pin (that's from 128 to 256 entries depending on the SoC). To make even more complicated, the padconf registers offset for GPIO pins are SoC specific so we need a mapping for each SoC. So I wonder if is worth to add all that information to the DTS files. Athough on the other hand is nice to have a better coordination between the GPIO and pinctrl drivers and as Tony said there are use cases where this is needed to workaround some silicion erratas. If we do this, we also need a solution to prevent automatic remuxing of GPIO pins from happending. For wake-up events, some drivers need to remux a rx pin to GPIO input for the duration of idle, and then back to device rx pin. This is needed on some other platforms too AFAIK. For the drivers needing GPIO wake-up events, request_gpio is done in the driver after drivers/base/pinctrl.c has already muxed the device pin to rx. At minimum we would get warnings about reserved pins if we tried to automatically mux them to GPIO. We may be able to use some GPIO specific property to prevent automatic remuxing as we discussed in the #armlinux few days ago. Yes, adding a GPIO specific property to prevent automatic remuxing sounds sensible to me. Related to automatic remuxing of GPIO pins, there are also other needs for pinctrl and GPIO interaction. We need to remux GPIO output pins to input + pull + safe_mode to prevent the GPIO pins losing value briefly during off-idle. That's the gpio errata 1.158 at as shown at least at [1]. Because the GPIO to pinctrl mapping is sparse and SoC specific, there's currently now obvious way to do that. And we would need few new GPIO functions to tell pinctrl subsystem about the change. I'm not that familiar with the pinctrl-single driver but can't that errata be handled on pinctrl-single without the GPIO OMAP driver intervention? I mean if we already add the complete GPIO -- pin mapping using pinctrl-single,gpio-range then the pinctrl-single driver will know what pins can be muxed as GPIO and which ones were set as output with pinctrl_gpio_direction_output() and then can just mux these output GPIO pins to input + pull + safe_mode during off-idle. Or am I completely lost here? :-) Regards, Tony [1] https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch Best regards, Javier [0] commit 96c886987219e37395a160f8bd0d228509c1d4f0 Author: Javier Martinez Canillas jav...@dowhile0.org Date: Fri May 30 20:50:39 2014 +0200 gpio: omap: Make GPIO operations fall through pinctrl-single On OMAP platforms, there are two diferent hardware blocks for I/O multiplexing / pad configuration and GPIO control. So two different drivers are used: pinctrl-single and gpio-omap. Since two separate drivers are used there is no coordination between these and a I/O pad is not configured as a GPIO when a GPIO pin is requested. This patch adds pinctrl back-end commands to the GPIO OMAP driver so the pinmux_ops functions in the pinctrl-single driver are called for each GPIO operation. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 00f29aa..cee63c6 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -27,6 +27,7 @@ #include linux/irqchip/chained_irq.h #include linux/gpio.h #include linux/bitops.h +#include
Re: Accessing GPIOs from userspace using recent kernels
* Javier Martinez Canillas jav...@dowhile0.org [140530 12:41]: Hello Tony, On Fri, May 23, 2014 at 5:11 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [140523 04:36]: On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote: The current call chain seems to be: gpiod_export() -- gpiod_request() -- omap_gpio_request(). Looking at other GPIO drivers, it seems like omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be useful if someone who knows about OMAP4/gpio/pinctrl could take a look at this. I looked briefly at adding pinctrl back-end commands to the OMAP GPIO driver. That is to make all GPIO operations fall through to the pinctrl-single driver as Linus suggested before. The changes in the GPIO driver are quite trivial, here is a RFC patch [0] that has only build tested but I think is useful to at least discuss this. Now, in order to make that patch to actually work someone has to register the chip GPIO range to pin controller mapping with gpiochip_add_pin_range() or something similar to make pinctrl_get_device_gpio_range() to succeed. The pinctrl-single driver has a pinctrl-single,gpio-range property that can be used to define a GPIO range to be registered. But the problem is as you said that since there are two different hw blocks for pin muxing and GPIO control, the pins that can be multiplexed as GPIO are scattered all over the padconf registers address space. So there isn't an easy way to specify the mapping and we will have to add an entry on pinctrl-single,gpio-range for every single GPIO pin (that's from 128 to 256 entries depending on the SoC). Yes. To make even more complicated, the padconf registers offset for GPIO pins are SoC specific so we need a mapping for each SoC. So I wonder if is worth to add all that information to the DTS files. Athough on the other hand is nice to have a better coordination between the GPIO and pinctrl drivers and as Tony said there are use cases where this is needed to workaround some silicion erratas. I don't see any way around it short of adding the gpio to pinctrl mappings for each SoC, and not do remuxing if the mapping is missing. Then we need to make sure that the pinctrl register mappings are the same for each SoC revision and package. If there are revision or package specific changes, we'd have to handle those too somehow by specifying the package with a compatible value in the board specific .dts file or something like that. If we do this, we also need a solution to prevent automatic remuxing of GPIO pins from happending. For wake-up events, some drivers need to remux a rx pin to GPIO input for the duration of idle, and then back to device rx pin. This is needed on some other platforms too AFAIK. For the drivers needing GPIO wake-up events, request_gpio is done in the driver after drivers/base/pinctrl.c has already muxed the device pin to rx. At minimum we would get warnings about reserved pins if we tried to automatically mux them to GPIO. We may be able to use some GPIO specific property to prevent automatic remuxing as we discussed in the #armlinux few days ago. Yes, adding a GPIO specific property to prevent automatic remuxing sounds sensible to me. OK that probably needs to be discussed separately. Related to automatic remuxing of GPIO pins, there are also other needs for pinctrl and GPIO interaction. We need to remux GPIO output pins to input + pull + safe_mode to prevent the GPIO pins losing value briefly during off-idle. That's the gpio errata 1.158 at as shown at least at [1]. Because the GPIO to pinctrl mapping is sparse and SoC specific, there's currently now obvious way to do that. And we would need few new GPIO functions to tell pinctrl subsystem about the change. I'm not that familiar with the pinctrl-single driver but can't that errata be handled on pinctrl-single without the GPIO OMAP driver intervention? No, it needs to happen from the GPIO driver based on runtime PM calls. Only the GPIO driver knows when a GPIO output value is being changed. I mean if we already add the complete GPIO -- pin mapping using pinctrl-single,gpio-range then the pinctrl-single driver will know what pins can be muxed as GPIO and which ones were set as output with pinctrl_gpio_direction_output() and then can just mux these output GPIO pins to input + pull + safe_mode during off-idle. Or am I completely lost here? :-) What about when a driver does gpio_set_value()? :) [1] https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch [0] commit 96c886987219e37395a160f8bd0d228509c1d4f0 Author: Javier Martinez Canillas jav...@dowhile0.org Date: Fri May 30 20:50:39 2014 +0200 gpio: omap: Make GPIO operations fall through pinctrl-single On OMAP platforms, there are two diferent hardware
Re: Accessing GPIOs from userspace using recent kernels
Hello Tony, On Fri, May 30, 2014 at 10:25 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [140530 12:41]: Hello Tony, On Fri, May 23, 2014 at 5:11 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [140523 04:36]: On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote: The current call chain seems to be: gpiod_export() -- gpiod_request() -- omap_gpio_request(). Looking at other GPIO drivers, it seems like omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be useful if someone who knows about OMAP4/gpio/pinctrl could take a look at this. I looked briefly at adding pinctrl back-end commands to the OMAP GPIO driver. That is to make all GPIO operations fall through to the pinctrl-single driver as Linus suggested before. The changes in the GPIO driver are quite trivial, here is a RFC patch [0] that has only build tested but I think is useful to at least discuss this. Now, in order to make that patch to actually work someone has to register the chip GPIO range to pin controller mapping with gpiochip_add_pin_range() or something similar to make pinctrl_get_device_gpio_range() to succeed. The pinctrl-single driver has a pinctrl-single,gpio-range property that can be used to define a GPIO range to be registered. But the problem is as you said that since there are two different hw blocks for pin muxing and GPIO control, the pins that can be multiplexed as GPIO are scattered all over the padconf registers address space. So there isn't an easy way to specify the mapping and we will have to add an entry on pinctrl-single,gpio-range for every single GPIO pin (that's from 128 to 256 entries depending on the SoC). Yes. To make even more complicated, the padconf registers offset for GPIO pins are SoC specific so we need a mapping for each SoC. So I wonder if is worth to add all that information to the DTS files. Athough on the other hand is nice to have a better coordination between the GPIO and pinctrl drivers and as Tony said there are use cases where this is needed to workaround some silicion erratas. I don't see any way around it short of adding the gpio to pinctrl mappings for each SoC, and not do remuxing if the mapping is missing. Then we need to make sure that the pinctrl register mappings are the same for each SoC revision and package. If there are revision or package specific changes, we'd have to handle those too somehow by specifying the package with a compatible value in the board specific .dts file or something like that. Agreed. If we do this, we also need a solution to prevent automatic remuxing of GPIO pins from happending. For wake-up events, some drivers need to remux a rx pin to GPIO input for the duration of idle, and then back to device rx pin. This is needed on some other platforms too AFAIK. For the drivers needing GPIO wake-up events, request_gpio is done in the driver after drivers/base/pinctrl.c has already muxed the device pin to rx. At minimum we would get warnings about reserved pins if we tried to automatically mux them to GPIO. We may be able to use some GPIO specific property to prevent automatic remuxing as we discussed in the #armlinux few days ago. Yes, adding a GPIO specific property to prevent automatic remuxing sounds sensible to me. OK that probably needs to be discussed separately. Ok. Related to automatic remuxing of GPIO pins, there are also other needs for pinctrl and GPIO interaction. We need to remux GPIO output pins to input + pull + safe_mode to prevent the GPIO pins losing value briefly during off-idle. That's the gpio errata 1.158 at as shown at least at [1]. Because the GPIO to pinctrl mapping is sparse and SoC specific, there's currently now obvious way to do that. And we would need few new GPIO functions to tell pinctrl subsystem about the change. I'm not that familiar with the pinctrl-single driver but can't that errata be handled on pinctrl-single without the GPIO OMAP driver intervention? No, it needs to happen from the GPIO driver based on runtime PM calls. Only the GPIO driver knows when a GPIO output value is being changed. I mean if we already add the complete GPIO -- pin mapping using pinctrl-single,gpio-range then the pinctrl-single driver will know what pins can be muxed as GPIO and which ones were set as output with pinctrl_gpio_direction_output() and then can just mux these output GPIO pins to input + pull + safe_mode during off-idle. Or am I completely lost here? :-) What about when a driver does gpio_set_value()? :) Right, I didn't thought about that... [1] https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch [0] commit 96c886987219e37395a160f8bd0d228509c1d4f0 Author: Javier Martinez Canillas jav...@dowhile0.org Date: Fri May 30
Re: Accessing GPIOs from userspace using recent kernels
Hi Peter, I think you have already understood from the rest of the conversation that pin control configuration shall be done in the device tree and not from userspace, which is a good start. As shown by Javier many things people sometimes do in userspace should rather be done in kernelspace, such as controlling LEDs and reading pushbuttons etc. On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote: On 2014-05-15 19:54, Javier Martinez Canillas wrote: 0x5e (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_sda.hdmi_sda */ 0x12e (PIN_OUTPUT | MUX_MODE5) /* dispc2_data15 */ Yes, that's my mistake. I took the pin control register addresses from the OMAP4 documentation and forgot that you have to subtract 0x40 to get the correct address for use in the device tree. The correct snippet has 0x1e and 0xee. I find the pinctrl-single hexdigit syntax infinitely complex and confusing, but it was chosen by its designers. Most drivers use strings to configure muxing and biasing etc. Is what you shared your real change or just an example that does not apply to the Pandaboard? Could you please share your complete DTS? The attached .dts file sort of works-ish. It's an ugly hack, but I don't have the time to do any more investigation into this now, unfortunately. I guess my main question is: if I use /sys/class/gpio/export to export a GPIO for userspace control, Which you should avoid, if possible. it would make sense for the kernel to try and ensure that the GPIO is actually connected to something! How should we do that? The physics of that request evades me. The pin control subsystem will however refuse to use the pin if it is used for something else. The current call chain seems to be: gpiod_export() -- gpiod_request() -- omap_gpio_request(). Looking at other GPIO drivers, it seems like omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be useful if someone who knows about OMAP4/gpio/pinctrl could take a look at this. That is Tony Lindgren and the linux-omap mailing list. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Accessing GPIOs from userspace using recent kernels
* Linus Walleij linus.wall...@linaro.org [140523 04:36]: On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote: The current call chain seems to be: gpiod_export() -- gpiod_request() -- omap_gpio_request(). Looking at other GPIO drivers, it seems like omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be useful if someone who knows about OMAP4/gpio/pinctrl could take a look at this. If we do this, we also need a solution to prevent automatic remuxing of GPIO pins from happending. For wake-up events, some drivers need to remux a rx pin to GPIO input for the duration of idle, and then back to device rx pin. This is needed on some other platforms too AFAIK. For the drivers needing GPIO wake-up events, request_gpio is done in the driver after drivers/base/pinctrl.c has already muxed the device pin to rx. At minimum we would get warnings about reserved pins if we tried to automatically mux them to GPIO. We may be able to use some GPIO specific property to prevent automatic remuxing as we discussed in the #armlinux few days ago. Related to automatic remuxing of GPIO pins, there are also other needs for pinctrl and GPIO interaction. We need to remux GPIO output pins to input + pull + safe_mode to prevent the GPIO pins losing value briefly during off-idle. That's the gpio errata 1.158 at as shown at least at [1]. Because the GPIO to pinctrl mapping is sparse and SoC specific, there's currently now obvious way to do that. And we would need few new GPIO functions to tell pinctrl subsystem about the change. Regards, Tony [1] https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
