RE: [PATCH v2] leds: leds-gpio: adopt pinctrl support
From: AnilKumar, Chimata <hidden>
Date: 2012-10-01 07:03:47
Also in:
linux-arm-kernel, linux-omap
+Don Aisheng On Tue, Sep 11, 2012 at 01:10:12, Linus Walleij wrote:
On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch [off-list ref] wrote:quoted
Adopt pinctrl support to leds-gpio driver based on leds-gpio device pointer, pinctrl driver configure SoC pins to GPIO mode according to definitions provided in .dts file. Signed-off-by: AnilKumar Ch <redacted>So looking back at this after Stephen posed a real good question, when you say "configure SoC pins to GPIO mode", does that mean anything else than to mux them into GPIO mode?
pinctrl-single.c driver sets mux mode as well as pin configuration like pull-up/pull-down, input/output and slew rate.
In that case, have you considered augmenting pinctrl-single.c to implement .gpio_request_enable() .gpio_disable_free() and maybe also .gpio_set_direction() in its struct pinmux_ops pinmux backend? If not, why?
Recently, I have gone through the details on implementing gpio_request_enable in pinctrl-single driver. To add this functionality we have to add gpio_range's to pinctrl driver. AM335x EVM supports total 128 GPIO pins (4 banks) and these are randomly distributed across AM33XX SoC pins. These are the concerns/questions I have:- 1. I haven't added yet but it will come to more than 30-40 pinctrl_gpio_range entries 2. If the silicon package is changed then these will change. 3. If the GPIO driver is common for multiple SoCs then these entries will be more & more over SoC specific and driver has to change every time the gpio_range changes. I have gone through the "Don Aisheng" patch series, which adds "pinctrl_dt_add_gpio_ranges" support but not accepted yet. With this patch series we can overcome the driver changes. 4. The current pinctrl driver has support for these APIs pinctrl_request_gpio(), pinctrl_free_gpio(), pinctrl_gpio_direction_input/output() no API for slew rate control, pulled down/up control how can we handle this? 5. pinctrl-single driver has to modify to provide separate handles for pinmux and pinconfig. And we need separate pin configuration bit masks and values/flags to take care of pull-up/down, slew rate, receiver in/out and mux mode control. 6. This is for my understanding, on which node do we have to add pinctrl data i.e., pin mux-mode data. In leds-gpio node (mostly not) and if it is in gpio node then how can we pass pinmux data with the existing API pinctrl_request_gpio(gpio);? Here we are passing only gpio number. Few more driver patches are pending along with this (leds-gpio DT data additions according to this patch, similarly other drivers like matrix keypad and volume keys) Thanks AnilKumar