linux-toradex.git/drivers/pinctrl/vt8500, branch v4.9.8

pinctrl: vt8500: Use devm_pinctrl_register() for pinctrl registration

2016-04-21T07:23:20+00:00

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan 
Cc: Lee Jones 
Cc: Heiko Stuebner 
Cc: Mika Westerberg 
Cc: Hongzhou Yang 
Signed-off-by: Linus Walleij

pinctrl: vt8500-wmt: use gpiochip data pointer

2016-01-05T13:15:08+00:00

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Heiko Stuebner 
Signed-off-by: Linus Walleij

gpio: change member .dev to .parent

2015-11-19T08:24:35+00:00

The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen 
Cc: Rafał Miłecki 
Cc: Richard Purdie 
Cc: Mauro Carvalho Chehab 
Cc: Alek Du 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Acked-by: Dmitry Torokhov 
Acked-by: Greg Kroah-Hartman 
Acked-by: Lee Jones 
Acked-by: Jiri Kosina 
Acked-by: Hans-Christian Egtvedt 
Acked-by: Jacek Anaszewski 
Signed-off-by: Linus Walleij

pinctrl: replace trivial implementations of gpio_chip request/free

2015-10-16T20:20:21+00:00

Replace all trivial request/free callbacks that do nothing but call into
pinctrl code with the generic versions.

Signed-off-by: Jonas Gorski 
Acked-by: Bjorn Andersson 
Acked-by: Heiko Stuebner 
Acked-by: Eric Anholt 
Acked-by: Mika Westerberg 
Acked-by: Andrew Bresticker 
Acked-by: Baruch Siach 
Acked-by: Matthias Brugger 
Acked-by: Lee Jones 
Acked-by: Laxman Dewangan 
Acked-by: Maxime Ripard 
Signed-off-by: Linus Walleij

pinctrl: make pinctrl_register() return proper error code

2015-06-10T12:49:52+00:00

Currently, pinctrl_register() just returns NULL on error, so the
callers can not know the exact reason of the failure.

Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some
-ENOMEM on error of pinctrl_register(), although the error code
might be different from the real cause of the error.

This commit reworks pinctrl_register() to return the appropriate
error code and modifies all of the pinctrl drivers to use IS_ERR()
for the error checking and PTR_ERR() for getting the error code.

Signed-off-by: Masahiro Yamada 
Acked-by: Patrice Chotard 
Acked-by: Thierry Reding 
Acked-by: Heiko Stuebner 
Tested-by: Mika Westerberg 
Acked-by: Mika Westerberg 
Acked-by: Lee Jones 
Acked-by: Sören Brinkmann 
Acked-by: Laurent Pinchart 
Acked-by: Ray Jui 
Acked-by: Antoine Tenart 
Acked-by: Hongzhou Yang 
Acked-by: Wei Chen 
Signed-off-by: Linus Walleij

pinctrl: constify of_device_id array

2015-03-27T08:58:35+00:00

of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)

Signed-off-by: Fabian Frederick 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Acked-by: Patrice Chotard 
Acked-by: Maxime Coquelin 
Acked-by: Hongzhou Yang 
Acked-by: Lee Jones 
Signed-off-by: Linus Walleij

pinctrl: vt8500: drop owner assignment from platform_drivers

2014-10-20T14:21:26+00:00

A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang

pinctrl: clean up after enable refactoring

2014-09-04T08:05:07+00:00

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: remove all usage of gpio_remove ret val in driver/pinctl

2014-07-22T14:34:12+00:00

Signed-off-by: abdoulaye berthe 
Signed-off-by: Linus Walleij

pinctrl: avoid duplicated calling enable_pinmux_setting for a pin

2014-07-11T12:08:26+00:00

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