On Tuesday 10 September 2013, Linus Walleij wrote: > The platform using this beeper has support for gpiolib, so there > is no point to use the custom gpio_line* API. A strange ambiguity > where a line was first set as input and then driven high was > solved by first driving the line high as output and then switch > it to input. > > Cc: Imre Kaloz <[email protected]> > Cc: Krzysztof Halasa <[email protected]> > Cc: Alexandre Courbot <[email protected]> > Cc: Arnd Bergmann <[email protected]> > Cc: Greg Kroah-Hartman <[email protected]> > Signed-off-by: Linus Walleij <[email protected]> > --- > Arnd/Greg: seeking your ACK to take this through the GPIO tree > as part of the attempt at cleaning out custom GPIO implementations.
Acked-by: Arnd Bergmann <[email protected]> > > - if (count) { > - gpio_line_config(pin, IXP4XX_GPIO_OUT); > - gpio_line_set(pin, IXP4XX_GPIO_LOW); > - > + if (count) { > + gpio_direction_output(pin, 0); > *IXP4XX_OSRT2 = (count & ~IXP4XX_OST_RELOAD_MASK) | > IXP4XX_OST_ENABLE; > } else { Too bad we can't just clean up all the open-coded mmio accesses as well. It shouldn't be hard, but some platforms are full of them, and there is definitely some regression potential. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
