user/sven/linux.git/include/linux/pinctrl, branch v3.9

pinctrl: generic: rename input schmitt disable

2013-02-15T08:52:29Z

Rename PIN_CONFIG_INPUT_SCHMITT_DISABLE to PIN_CONFIG_INPUT_SCHMITT_ENABLE. It's used to make it more generialize. Signed-off-by: Haojian Zhuang Acked-by: Tony Lindgren Signed-off-by: Linus Walleij

drivers/pinctrl: grab default handles from device core

2013-01-23T15:39:51Z

This makes the device core auto-grab the pinctrl handle and set the "default" (PINCTRL_STATE_DEFAULT) state for every device that is present in the device model right before probe. This will account for the lion's share of embedded silicon devcies. A modification of the semantics for pinctrl_get() is also done: previously if the pinctrl handle for a certain device was already taken, the pinctrl core would return an error. Now, since the core may have already default-grabbed the handle and set its state to "default", if the handle was already taken, this will be disregarded and the located, previously instanitated handle will be returned to the caller. This way all code in drivers explicitly requesting their pinctrl handlers will still be functional, and drivers that want to explicitly retrieve and switch their handles can still do that. But if the desired functionality is just boilerplate of this type in the probe() function: struct pinctrl *p; p = devm_pinctrl_get_select_default(&dev); if (IS_ERR(p)) { if (PTR_ERR(p) == -EPROBE_DEFER) return -EPROBE_DEFER; dev_warn(&dev, "no pinctrl handle\n"); } The discussion began with the addition of such boilerplate to the omap4 keypad driver: http://marc.info/?l=linux-input&m=135091157719300&w=2 A previous approach using notifiers was discussed: http://marc.info/?l=linux-kernel&m=135263661110528&w=2 This failed because it could not handle deferred probes. This patch alone does not solve the entire dilemma faced: whether code should be distributed into the drivers or if it should be centralized to e.g. a PM domain. But it solves the immediate issue of the addition of boilerplate to a lot of drivers that just want to grab the default state. As mentioned, they can later explicitly retrieve the handle and set different states, and this could as well be done by e.g. PM domains as it is only related to a certain struct device * pointer. ChangeLog v4->v5 (Stephen): - Simplified the devicecore grab code. - Deleted a piece of documentation recommending that pins be mapped to a device rather than hogged. ChangeLog v3->v4 (Linus): - Drop overzealous NULL checks. - Move kref initialization to pinctrl_create(). - Seeking Tested-by from Stephen Warren so we do not disturb the Tegra platform. - Seeking ACK on this from Greg (and others who like it) so I can merge it through the pinctrl subsystem. ChangeLog v2->v3 (Linus): - Abstain from using IS_ERR_OR_NULL() in the driver core, Russell recently sent a patch to remove it. Handle the NULL case explicitly even though it's a bogus case. - Make sure we handle probe deferral correctly in the device core file. devm_kfree() the container on error so we don't waste memory for devices without pinctrl handles. - Introduce reference counting into the pinctrl core using so that we don't release pinctrl handles that have been obtained for two or more places. ChangeLog v1->v2 (Linus): - Only store a pointer in the device struct, and only allocate this if it's really used by the device. Cc: Felipe Balbi Cc: Benoit Cousson Cc: Dmitry Torokhov Cc: Thomas Petazzoni Cc: Mitch Bradley Cc: Ulf Hansson Cc: Rafael J. Wysocki Cc: Jean-Christophe PLAGNIOL-VILLARD Cc: Rickard Andersson Cc: Russell King Reviewed-by: Mark Brown Acked-by: Greg Kroah-Hartman Signed-off-by: Linus Walleij [swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to correctly handle deferred probe. Removed admonition from docs not to use pinctrl hogs for devices] Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij

pinctrl: generic: add slew rate config parameter

2013-01-21T14:43:42Z

Add PIN_CONFIG_SLEW_RATE parameter into pinconf-generic driver. Signed-off-by: Haojian Zhuang Signed-off-by: Linus Walleij

pinctrl: core: get devname from pinctrl_dev

2013-01-21T14:14:39Z

Add new function to get devname from pinctrl_dev. pinctrl_dev_get_name() can only get pinctrl description name. If we want to use gpio driver to find pinctrl device node, we need to fetch the pinctrl device name. Signed-off-by: Haojian Zhuang Signed-off-by: Linus Walleij

pinctrl: pinconf-generic: add drive strength parameter

2013-01-18T15:16:28Z

Some pin configurations IP allows to set the current output to the pin. This patch adds such a parameter to the pinconf-generic mechanism. This parameter takes as argument the drive strength in mA. Signed-off-by: Maxime Ripard Signed-off-by: Linus Walleij

pinctrl: add pinconf-generic defines for output

2013-01-11T20:49:20Z

This adds a definition of a generic output configuration for a certain pin when using the generic pin configuration library. Whereas driving pins low/high is usually a GPIO business, you may want to set up pins into a default state using hogs, and never touch them again. This helps out with that scenario. Based on a patch from Patrice Chotard. Signed-off-by: Patrice Chotard Reviewed-by: Stephen Warren Signed-off-by: Linus Walleij

pinctrl: generic: add input schmitt disable parameter

2012-11-21T07:55:26Z

In Marvell PXA/MMP silicons, input schmitt disable value is 0x40, not 0. So append new config parameter -- input schmitt disable. Signed-off-by: Haojian Zhuang Signed-off-by: Linus Walleij

pinctrl: add function to retrieve range from pin

2012-11-21T07:55:12Z

This adds a function to the pinctrl core to retrieve the GPIO range associated with a certain pin for a certain controller. This is needed when a pinctrl driver want to look up the corresponding struct gpio_chip for a certain pin. As the GPIO drivers can now create these ranges themselves, the pinctrl driver no longer knows about all its associated GPIO chips. Reviewed-by: Stephen Warren Reviewed-by: Viresh Kumar Signed-off-by: Linus Walleij

gpiolib: rename find_pinctrl_*

2012-11-21T07:55:10Z

Rename the function find_pinctrl_and_add_gpio_range() to pinctrl_find_and_add_gpio_range() so as to be consistent with the rest of the functions. Reviewed-by: Stephen Warren Reviewed-by: Viresh Kumar Signed-off-by: Linus Walleij

gpiolib: separation of pin concerns

2012-11-11T18:06:07Z

The fact that of_gpiochip_add_pin_range() and gpiochip_add_pin_range() share too much code is fragile and will invariably mean that bugs need to be fixed in two places instead of one. So separate the concerns of gpiolib.c and gpiolib-of.c and have the latter call the former as back-end. This is necessary also when going forward with other device descriptions such as ACPI. This is done by: - Adding a return code to gpiochip_add_pin_range() so we can reliably check whether this succeeds. - Get rid of the custom of_pinctrl_add_gpio_range() from pinctrl. Instead create of_pinctrl_get() to just retrive the pin controller per se from an OF node. This composite function was just begging to be deleted, it was way to purpose-specific. - Use pinctrl_dev_get_name() to get the name of the retrieved pin controller and use that to call back into the generic gpiochip_add_pin_range(). Now the pin range is only allocated and tied to a pin controller from the core implementation in gpiolib.c. Signed-off-by: Linus Walleij