Messages in this thread | | | From | Stephen Warren <> | Date | Mon, 14 Nov 2011 09:18:07 -0800 | Subject | RE: [PATCH] pinctrl: indicate GPIO direction on single GPIO request |
| |
Linus Walleij wrote at Monday, November 14, 2011 2:11 AM: > When requesting a single GPIO pin to be muxed in, some controllers > will need to poke a different value into the control register > depending on whether the pin will be used for GPIO output or GPIO > input. So pass this info along for the gpio_request_enable() > function, we assume this is not needed for the gpio_free_disable() > function for the time being.
I'm not sure this API change makes sense.
Functions gpio_direction_{input,output} already exist to configure the direction of a GPIO, and drivers should already be using them. These have to work to allow drivers to toggle the direction dynamically. Requiring them to additionally pass this same information to the pinmux driver when setting up the pinmux seems like extra redundant work.
Instead, shouldn't it work like this:
* If the pinmux driver implementation behind pinmux_request_gpio() needs to know the direction when configuring the HW, default to input for safety; that will prevent the SoC driving a signal on a GPIO that's driven by some other device.
* Rely exclusively on gpio_direction_{input,output} to allow drivers to configure the direction.
* If the pinmux HW needs programming in response to the gpio_direction_* calls, have the GPIO and pinmux driver internally communicate to achieve this.
Does that seem reasonable?
-- nvpublic
| |