Messages in this thread | | | Date | Thu, 19 Dec 2013 18:13:04 +0100 | From | boris brezillon <> | Subject | Re: [RFC PATCH] gpio: add GPIO hogging mechanism |
| |
Hello Greg,
On 19/12/2013 17:41, Greg Kroah-Hartman wrote: > On Thu, Dec 19, 2013 at 03:34:31PM +0100, Boris BREZILLON wrote: >> GPIO hogging is a way to request and configure specific GPIO without >> explicitly requesting it in the device driver. >> >> The request and configuration procedure is handled in the core device >> driver code before the driver probe function is called. >> >> It allows specific GPIOs to be configured without any driver specific code. >> >> Particularly usefull when a external device is connected to a bus and the >> bus connections depends on an external switch controlled by a GPIO pin. >> Or when some GPIOs have to be exported to sysfs without any userspace >> intervention. >> >> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> >> --- >> Documentation/devicetree/bindings/gpio/gpio.txt | 47 ++++++++ >> drivers/base/Makefile | 1 + >> drivers/base/dd.c | 5 + >> drivers/base/gpio.c | 59 ++++++++++ > I don't understand what makes GPIO's "special" enough to get included in > the driver core like this, and called for each and every device that is > added to the system.
> What's wrong with the generic device callbacks/notifiers we already > have? Why does this need to be in the driver core? And what exactly > are you doing all of this for in the first place?
Nothing's wrong with the generic device callbacks/notifiers, but in some cases we don't want a generic driver to handle board specificities.
This is the case for the at91rm9200ek board (see this thread: https://www.mail-archive.com/devicetree@vger.kernel.org/msg06838.html).
Since we are moving all boards to dt, we can't configure each board at startup, and the rm9200ek board used to set a pin to a specific value (this pin is connected to an external switch which connects MMC signals to the MMC connector or SPI signals to an SPI device depending on the pin value) in order to enable the MMC0 port or an SPI device.
I first proposed to handle this using a pinctrl pinconf definition (with pinctrl output-high config). As pinctrl are requesting pinconf before calling driver probe function, this was absolutely transparent to the generic driver. But, as Linus pointed out, this pin is not really related to the SPI or MMC device itself. This is why Linus suggested the GPIO hog approach.
Anyway, I'm open to any other solution that wouldn't introduce specific cases in arch specific code or generic drivers.
Best Regards,
Boris > greg k-h
| |