On Fri, Sep 07, 2012 at 09:10:50AM +0000, AnilKumar, Chimata wrote: > Hi Domenico,
Hi, > On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote: > > On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch <anilku...@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. > > > > Shouldn't be the interaction with the pinctrl layer left to gpiolib? > > > > No, these gpio's are configured specifically for user leds. So there are some special pad configs to make the leds work which are not only muxing and direction setting? Because I expect these to be managed privately between gpiolib and pinctrl but now I'm not sure any more, I'll look the code. > So, leds-gpio driver should have this call, because these gpio > pins are used by leds-gpio driver. > > + am33xx_pinmux: pinmux@44e10800 { > + userled_pins: pinmux_userled_pins { > + pinctrl-single,pins = < > + 0x54 0x7 > + 0x58 0x17 > + 0x5c 0x7 > + 0x60 0x17 > + >; > + }; > + }; > + > > [...] > > + leds { > + compatible = "gpio-leds"; > + pinctrl-names = "default"; > + pinctrl-0 = <&userled_pins>; > ^^^^^^^^^^^^ I'm surprised to not see any gpio controller (ala irq) involved. > Lets take gpio-keypad driver, in that case we have to configure > pins as INPUT mode (generic gpio driver might not know what > the end usecase is) and this leds case we configure as OUTPUT > mode. gpio direction is modeled by gpiolib so, if no other out-of-gpiolib capabilities are required for that led gpio, there is no need to directly use pinctrl. maybe I've just got it wrong. sorry. thanks, Domenico -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html