2009/2/9 David Brownell <david-b@xxxxxxxxxxx>: > On Sunday 08 February 2009, Joonyoung Shim wrote: >> > Which should clearly be AE6_34XX_GPIO141_OUT since it does >> > not enable the input driver. Try making that ...PIN_OUTPUT >> > read ...PIN_INPUT and see if things behave. >> >> Of course, it will be better if the name is clear as AE6_34XX_GPIO141_OUT. >> but, the core of this problem is not it, the chip->get() called in >> gpiolib_dbg_show() >> of drivers/gpio/gpiolib.c or dbg_gpio_show() of arch/arm/plat-omap/gpio.c >> can return the wrong value when gpio pin is configured as an output. > > No, the core of the problem is that you're using a GPIO > which is explicitly configured as output-only ... but are > treating it as if it were a normal bi-directional GPIO. > > It's acting *exactly* right for an output-only GPIO. But > that's not the behavior you expect, or want. > > If you weren't disabling the input driver, then when you > ask for the input value it would work as you expect. Which > is why I suggested you change how that ball is configured. > (That's actually a bugfix to those muxing tables ...) I understood that you say, ths PIN_OUTPUT flag must use when GPIO pin is output-only, and i got the result i want after GPIO pin is configured as bi-diretional GPIO. But i wonder why don't control in gpio_get() of arch/arm/plat-omap/gpio.c when the GPIO pin is output-only? thank you. - Joonyoung > > - Dave > > p.s. This specific confusion is new on OMAP3; previous > OMAPs didn't have the extra byte of options to > configure. The PIN_INPUT flag was, on previous > chips, effectively hard-wired on for GPIOs. > -- 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
