Thread (4 messages) 4 messages, 3 authors, 2012-10-01

[PATCH v2] leds: leds-gpio: adopt pinctrl support

From: AnilKumar, Chimata <hidden>
Date: 2012-10-01 07:03:47
Also in: linux-devicetree, linux-omap

Possibly related (same subject, not in this thread)

+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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help