+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@xxxxxx> 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@xxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
