Messages in this thread | | | Date | Wed, 20 Apr 2011 16:29:58 +0100 | From | Alan Cox <> | Subject | Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib |
| |
> Some people inevitably think that GPIO and pin/padmux are > intertwined, but as far as I have seen they are not. However there
It's not just pin muxing - gpio pins are sometimes shared between firmware and OS and belong to one or the other depending upon what is going on. For example the OS may need to own the pin for things like updating or eeprom writing but the firmware or another device owns it for day to day processing.
> may be a cross dependency so that a GPIO driver may need to > export an additional pin/padmux interface or so, e.g we have > a separate chip in I2C which can mux pins...
Would it not make sense to assume that given a situation where you have a GPIO that can be routed four ways that you actually implement it like the rest of the kernel - ie
r = gpio_request(n); /* n, n+1, n+2, n+3 are the four ways */
if (r < 0) /* EBUSY - someone else is using one of the four */ return -EBUSY; /* Succeeded - will also have set the mux for us */
At that point drivers don't need to know if a GPIO is muxed it'll just be busy if someone else is using it.
It seems to me that if the goal of the gpio layer is to provide an abstraction then it can abstract muxes just fine and without needing drivers to know.
Alan
| |