linux-toradex.git/drivers/pinctrl/pinctrl-at91.c, branch v3.17-rc6

pinctrl: pinctrl-at91.c: fix decimal printf format specifiers prefixed with 0x

2014-08-17T14:15:44+00:00

The prefix suggests the number should be printed in hex, so use
the %x specifier to do that.

Found by using regex suggested by Joe Perches.

Signed-off-by: Hans Wennborg 
Acked-by: Alexandre Belloni 
Signed-off-by: Linus Walleij

pinctrl: pinctrl-at91.c: Cleaning up values that are never used

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

Remove variable that are never used

This was found using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist 
Signed-off-by: Linus Walleij

pinctrl: pinctrl-at91.c: Cleaning up if unsigned is less than zero

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

Remove checking if a unsigned is less than zero

This was found using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist 
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

pinctrl/at91: Fix lockup when IRQ on PIOC and PIOD occurs

2014-05-27T09:13:10+00:00

With commit 80cc3732 (pinctrl/at91: convert driver to use gpiolib irqchip)
gpiochip_set_chained_irqchip is called for PIOC, PIOD and PIOE. The
associated GPIO chip for the IRQ chip is overwritten each time, because
they share the same hard IRQ line.
Thus if an IRQ occurs on PIOC or PIOD, gpio_irq_handler will only check on
PIOE (the assigned GPIO chip) where no event occured. Thus the IRQ will
not be cleared, retriggering the ISR.
Fix that (like done before) by only set the PIOC GPIO chip to the IRQ chip
and walk the list in the irq handler.

Signed-off-by: Alexander Stein 
Signed-off-by: Linus Walleij

pinctrl/at91: Fix mask creation in at91_gpio_dbg_show

2014-04-22T21:45:57+00:00

pin_to_mask expects a bank pin number. So do not add the chip base.

Without that patch cat /sys/kernel/debug/gpio looks like that:
GPIOs 0-31, platform/fffff200.gpio, fffff200.gpio:
[spi32766.0] GPIOfffff200.gpio5: [gpio] set
[ads7846_pendown] GPIOfffff200.gpio15: [gpio] set
[ohci_vbus] GPIOfffff200.gpio21: [gpio] set
[ohci_vbus] GPIOfffff200.gpio24: [gpio] set
[button1] GPIOfffff200.gpio28: [gpio] clear
[button2] GPIOfffff200.gpio29: [gpio] clear

GPIOs 32-63, platform/fffff400.gpio, fffff400.gpio:
[sda] GPIOfffff400.gpio4: [periph A]
[scl] GPIOfffff400.gpio5: [periph A]
[spi32766.3] GPIOfffff400.gpio11: [periph A]
[error] GPIOfffff400.gpio22: [periph A]
[run] GPIOfffff400.gpio23: [periph A]

GPIOs 64-95, platform/fffff600.gpio, fffff600.gpio:
[reset_pin] GPIOfffff600.gpio29: [periph A]

GPIOs 96-127, platform/fffff800.gpio, fffff800.gpio:
[led1] GPIOfffff800.gpio5: [periph A]
[led2] GPIOfffff800.gpio6: [periph A]
[led3] GPIOfffff800.gpio7: [periph A]
[led4] GPIOfffff800.gpio8: [periph A]

GPIOs 128-159, platform/fffffa00.gpio, fffffa00.gpio:
[button3] GPIOfffffa00.gpio10: [periph A]
[button4] GPIOfffffa00.gpio12: [periph A]

Note that every bank despite bank 0 only shows "periph A" which are
obviously used as GPIOs.

Signed-off-by: Alexander Stein 
Acked-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
Signed-off-by: Linus Walleij

pinctrl/at91: convert driver to use gpiolib irqchip

2014-04-22T21:37:21+00:00

This converts the AT91 pin control driver to register its
chained irq handler and irqchip using the helpers in the
gpiolib core.

Signed-off-by: Alexander Stein 
Signed-off-by: Linus Walleij

pinctrl: at91: implement get_direction

2014-02-25T09:49:15+00:00

This is needed for gpiod_get_direction().
Otherwise, it returns -EINVAL.

Signed-off-by: Richard Genoud 
Signed-off-by: Linus Walleij

pinctrl: at91: use gpiolib API to mark a GPIO used as an IRQ

2014-02-10T09:13:08+00:00

When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
the gpiolib so we can keep track of the usage centrally.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Linus Walleij

pinctrl: at91: use locked variant of irq_set_handler

2014-02-03T08:07:30+00:00

When setting the gpio irq type, use the __irq_set_handler_locked()
variant instead of the irq_set_handler() to prevent false
spinlock recursion warning.

Signed-off-by: Nicolas Ferre 
Cc: stable  # v3.12
Signed-off-by: Linus Walleij