On Mon, Oct 1, 2012 at 9:03 AM, AnilKumar, Chimata <anilkumar@xxxxxx> wrote: > 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. OK then this is the direction we need to go. > 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? You are not supposed to handle that from the GPIO level of the API. That is supposed to be handled by pinctrl. These two subsystems are orthogonal, with the exception of the above calls. If you need to pass more information between the GPIO and pinctrl interfaces it usually means you're doing something wrong. The reason why pinctrl was created in the first place was that Grant didn't like that we started to shoehorn all kind of pin control into the GPIO subsystem. > 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. OK that is typical pinctrl driver implementation work. I hope Tony can advice on this? > 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. So with the pinctrl_request_gpio() call you are requesting a single pin to be used as GPIO, nothing else. No additional data should be passed with that call. Implementing it is up to the pinctrl driver, the pinctrl subsystem API does not say anything about how this should be done, but there are a few examples. The pinctrl maps of muxes and config from the pin control subsystem are for entire devices, and the single-pin GPIO reservation API is orthogonal to this, please consult Documentation/pinctrl.txt if you are uncertain about what I mean with this, I've really tried to explain it there. The docs were recently amended to reflect some corner-case GPIO uses, see e.g.: http://marc.info/?l=linux-arm-kernel&m=134763067415678&w=2 > 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) OK so the threshold is that we need to get it right for the first one and then the others will look good too. Yours, Linus Walleij -- 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
