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

[AnilKumar, Chimata]

+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 <anilkumar at ti.com> wrote:
> 
> > 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 <anilkumar at ti.com>
> 
> 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