pm24.git/drivers/pinctrl/core.c, branch v3.8

pinctrl: fix comment mistake

2012-12-26T00:59:52Z

This variable pertains to pinctrl handles not muxes specifically. 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

pinctrl: make range registration defer properly

2012-11-21T07:55:10Z

This makes the pinctrl_find_and_add_gpio_range() return -EPROBE_DEFER if the range hosting pin controller cannot be located. We may assume that the common case for why adding a range fails is that the targe pin controller device has not probed yet. 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: provide provision to register pin ranges

2012-11-11T18:06:00Z

pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which a given pinctrl driver can handle. This is important to handle pinctrl gpio request calls in order to program a given pin properly for gpio operation. As gpio base is allocated dynamically during gpiochip registration, presently there exists no clean way to pass this information to the pinctrl subsystem. After few discussions from [1], it was concluded that may be gpio controller reporting the pin range it supports, is a better way than pinctrl subsystem directly registering it. [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816 Cc: Grant Likely Signed-off-by: Viresh Kumar Signed-off-by: Shiraz Hashim [Edited documentation a bit] Signed-off-by: Linus Walleij

Revert "pinctrl: remove pinctrl_remove_gpio_range"

2012-11-11T18:05:59Z

This reverts earlier commit which removed pinctrl_remove_gpio_range(), because at that time there weren't any more users of that routine. It was removed as the removal of ranges was done in unregister of pinctrl. But as we are now registering stuff from gpiolib, we may remove and insert a gpio module multiple times. So, we need this routine again. Signed-off-by: Viresh Kumar Signed-off-by: Linus Walleij

pinctrl: reserve pins when states are activated

2012-11-11T18:05:56Z

This switches the way that pins are reserved for multiplexing: We used to do this when the map was parsed, at the creation of the settings inside the pinctrl handle, in pinmux_map_to_setting(). However this does not work for us, because we want to use the same set of pins with different devices at different times: the current code assumes that the pin groups in a pinmux state will only be used with one single device, albeit different groups can be active at different times. For example if a single I2C driver block is used to drive two different busses located on two pin groups A and B, then the pins for all possible states of a function are reserved when fetching the pinctrl handle: the I2C bus can choose either set A or set B by a mux state at runtime, but all pins in both group A and B (the superset) are effectively reserved for that I2C function and mapped to the device. Another device can never get in and use the pins in group A, even if the device/function is using group B at the moment. Instead: let use reserve the pins when the state is activated and drop them when the state is disabled, i.e. when we move to another state. This way different devices/functions can use the same pins at different times. We know that this is an odd way of doing things, but we really need to switch e.g. an SD-card slot to become a tracing output sink at runtime: we plug in a special "tracing card" then mux the pins that used to be an SD slot around to the tracing unit and push out tracing data there instead of SD-card traffic. As a side effect pinmux_free_setting() is unused but the stubs are kept for future additions of code. Cc: Patrice Chotard Cc: Loic Pallardy Acked-by: Stephen Warren Tested-by: Jean Nicolas Graux Signed-off-by: Linus Walleij

pinctrl: fix missing unlock on error in pinctrl_groups_show()

2012-10-23T08:35:10Z

Add the missing unlock on the error handle path in function pinctrl_groups_show(). Cc: stable@kernel.org Signed-off-by: Wei Yongjun Signed-off-by: Linus Walleij

pinctrl: Fix potential memory leak in pinctrl_register_one_pin()

2012-09-27T11:43:14Z

'pindesc' was not freed when returning from an error induced exit path. Signed-off-by: Sachin Kamat Signed-off-by: Linus Walleij

trivial: pinctrl core: remove extraneous code lines

2012-08-17T09:09:58Z

In function pinctrl_get_locked, pointer p is returned on error, and also return on no_error. So, we just return it with no error test. It's pretty the same in function pinctrl_lookup_state_locked: state is returned in every case, so we drop the error test and just return state. Signed-off-by: Richard Genoud