kernel.git/drivers/pinctrl/pinmux.c, branch linux-4.2.y

pinctrl: don't print unavailable function groups

2015-06-10T08:44:05Z

There is no reason to try to print groups associated to a function if get_function_groups returns an error. Moreover, it can lead to a NULL pointer dereference error. Signed-off-by: Ludovic Desroches Signed-off-by: Linus Walleij

pinctrl: improve debugfs for strict controllers

2015-05-28T08:14:21Z

If we know we are using a strict pin controller (one that cannot mix device functions+group use and GPIO) we can be a bit more specific in debugfs, just print either device-function-group or GPIO consumer for the pin. Let's do that to be helpful. Cc: Sonic Zhang Signed-off-by: Linus Walleij

pinctrl: move strict option to pinmux_ops

2015-05-06T12:45:19Z

While the pinmux_ops are ideally just a vtable for pin mux calls, the "strict" setting belongs so intuitively with the pin multiplexing that we should move it here anyway. Putting it in the top pinctrl_desc makes no sense. Cc: Sonic Zhang Signed-off-by: Linus Walleij

pinctrl: allow exlusive GPIO/mux pin allocation

2015-05-06T12:45:19Z

Disallow simultaneous use of the the GPIO and peripheral mux functions by setting a flag "strict" in struct pinctrl_desc. The blackfin pinmux and gpio controller doesn't allow user to set up a pin for both GPIO and peripheral function. So, add flag strict in struct pinctrl_desc to check both gpio_owner and mux_owner before approving the pin request. v2-changes: - if strict flag is set, check gpio_owner and mux_onwer in if and else clause v3-changes: - add kerneldoc for this struct - augment Documentation/pinctrl.txt Signed-off-by: Sonic Zhang Signed-off-by: Linus Walleij

pinctrl: clean up after enable refactoring

2014-09-04T08:05:07Z

commit 2243a87d90b42eb38bc281957df3e57c712b5e56 "pinctrl: avoid duplicated calling enable_pinmux_setting for a pin" removed the .disable callback from the struct pinmux_ops, making the .enable() callback the only remaining callback. However .enable() is a bad name as it seems to imply that a muxing can also be disabled. Rename the callback to .set_mux() and also take this opportunity to clean out any remaining mentions of .disable() from the documentation. Acked-by: Stephen Warren Acked-by: Bjorn Andersson Acked-by: Fan Wu Signed-off-by: Linus Walleij

pinctrl: avoid duplicated calling enable_pinmux_setting for a pin

2014-07-11T12:08:26Z

What the patch does: 1. Call pinmux_disable_setting ahead of pinmux_enable_setting each time pinctrl_select_state is called 2. Remove the HW disable operation in pinmux_disable_setting function. 3. Remove the disable ops in struct pinmux_ops 4. Remove all the disable ops users in current code base. Notes: 1. Great thanks for the suggestion from Linus, Tony Lindgren and Stephen Warren and Everyone that shared comments on this patch. 2. The patch also includes comment fixes from Stephen Warren. The reason why we do this: 1. To avoid duplicated calling of the enable_setting operation without disabling operation inbetween which will let the pin descriptor desc->mux_usecount increase monotonously. 2. The HW pin disable operation is not useful for any of the existing platforms. And this can be used to avoid the HW glitch after using the item #1 modification. In the following case, the issue can be reproduced: 1. There is a driver that need to switch pin state dynamically, e.g. between "sleep" and "default" state 2. The pin setting configuration in a DTS node may be like this: component a { pinctrl-names = "default", "sleep"; pinctrl-0 = <&a_grp_setting &c_grp_setting>; pinctrl-1 = <&b_grp_setting &c_grp_setting>; } The "c_grp_setting" config node is totally identical, maybe like following one: c_grp_setting: c_grp_setting { pinctrl-single,pins = ; } 3. When switching the pin state in the following official pinctrl sequence: pin = pinctrl_get(); state = pinctrl_lookup_state(wanted_state); pinctrl_select_state(state); pinctrl_put(); Test Result: 1. The switch is completed as expected, that is: the device's pin configuration is changed according to the description in the "wanted_state" group setting 2. The "desc->mux_usecount" of the corresponding pins in "c_group" is increased without being decreased, because the "desc" is for each physical pin while the setting is for each setting node in the DTS. Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount will keep increasing without any chance to be decreased. According to the comments in the original code, only the setting, in old state but not in new state, will be "disabled" (calling pinmux_disable_setting), which is correct logic but not intact. We still need consider case that the setting is in both old state and new state. We can do this in the following two ways: 1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin setting" repeatedly 2. "Disable"(calling pinmux_disable_setting) the "same pin setting", actually two setting instances, ahead of enabling them. Analysis: 1. The solution #2 is better because it can avoid too much iteration. 2. If we disable all of the settings in the old state and one of the setting(s) exist in the new state, the pins mux function change may happen when some SoC vendors defined the "pinctrl-single,function-off" in their DTS file. old_setting => disabled_setting => new_setting. 3. In the pinmux framework, when a pin state is switched, the setting in the old state should be marked as "disabled". Conclusion: 1. To Remove the HW disabling operation to above the glitch mentioned above. 2. Handle the issue mentioned above by disabling all of the settings in old state and then enable the all of the settings in new state. Signed-off-by: Fan Wu Acked-by: Stephen Warren Acked-by: Patrice Chotard Acked-by: Heiko Stuebner Acked-by: Maxime Coquelin Signed-off-by: Linus Walleij

pinctrl: allows not to define the get_group_pins operation

2014-04-22T12:47:02Z

When using a group only pinctrl driver, which does not have any information on the pins it is useless to define a get_group_pins always returning an empty list of pins. When not using get_group_pin[1], a driver must implement it so pins = NULL and num_pins = 0. This patch makes it the default behaviour if not defined in the pinctrl driver when used in pinmux enable and disable funtions and in pinctrl_groups_show. It also adds a check in pinctrl_get_group_pins and return -EINVAL if not defined. This function is called in the gpiolib when adding when pingroup range. It cannot be used if no group is defined, so this seams reasonable. [1] get_group_pin(struct pinctrl_dev *pctldev, unsigned selector, const unsigned **pins, unsigned *num_pins); Signed-off-by: Antoine TÃ©nart Signed-off-by: Linus Walleij

pinctrl: remove minor dead code

2013-11-04T12:07:05Z

This removes a test whether the 'desc' variable is NULL. This possibility has already been eliminated by the below test earlier in the loop: if (desc == NULL) { dev_warn(pctldev->dev, "could not get pin desc for pin %d\n", pins[i]); continue; } Found with Coverity: CID #1090078 Signed-off-by: Michael Opdenacker Signed-off-by: Linus Walleij

pinctrl: improve warning messages

2013-08-14T20:49:14Z

Print out the affected group name on activation of pin mux settings, and warn if you cannot free a pin that should have been part of a certain setting. ChangeLog v1->v2: - Also print the pin name in the error messages. Cc: Sonic Zhang Reviewed-by: Stephen Warren Signed-off-by: Linus Walleij

pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

2013-08-14T15:52:18Z

One peripheral may share part of its pins with the 2nd peripheral and the other pins with the 3rd. If it requests all pins when part of them has already be requested and owned by the 2nd peripheral, this request fails and pinmux_disable_setting() is called. The pinmux_disable_setting() frees all pins of the first peripheral without checking if the pin is owned by itself or the 2nd, which results in the malfunction of the 2nd peripheral driver. Signed-off-by: Sonic Zhang Signed-off-by: Linus Walleij