Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

[Alan Cox]

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/