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 <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.
> >
> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
