An error occurred fetching the project authors.
  1. 19 Sep, 2016 1 commit
  2. 27 Aug, 2016 1 commit
    • Paul Gortmaker's avatar
      pinctrl: nomadik: make core support explicitly non-modular · 6d6cc0d8
      Paul Gortmaker authored
      The Kconfig currently controlling compilation of this code is:
      
      drivers/pinctrl/nomadik/Kconfig:config PINCTRL_NOMADIK
      drivers/pinctrl/nomadik/Kconfig:        bool "Nomadik pin controller driver"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      Lets remove the couple traces of modular infrastructure use, so that
      when reading the driver there is no doubt it is builtin-only.
      
      We delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alessandro Rubini <rubini@unipv.it>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      6d6cc0d8
  3. 11 Aug, 2016 1 commit
  4. 13 Jun, 2016 1 commit
    • Ben Dooks's avatar
      pinctrl: nomadik: fix warnings from unexported functions · 27cdb5d0
      Ben Dooks authored
      There are five functions in the driver that are defined but
      only used locally. Since these are not used in the current
      kernel, delete them to avoid the following warnings:
      
      drivers/pinctrl/nomadik/pinctrl-nomadik.c:1036:6: warning: symbol 'nmk_gpio_clocks_enable' was not declared. Should it be static?
      drivers/pinctrl/nomadik/pinctrl-nomadik.c:1050:6: warning: symbol 'nmk_gpio_clocks_disable' was not declared. Should it be static?
      drivers/pinctrl/nomadik/pinctrl-nomadik.c:1073:6: warning: symbol 'nmk_gpio_wakeups_suspend' was not declared. Should it be static?
      drivers/pinctrl/nomadik/pinctrl-nomadik.c:1094:6: warning: symbol 'nmk_gpio_wakeups_resume' was not declared. Should it be static?
      drivers/pinctrl/nomadik/pinctrl-nomadik.c:1120:6: warning: symbol 'nmk_gpio_read_pull' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      27cdb5d0
  5. 30 May, 2016 1 commit
  6. 09 May, 2016 1 commit
    • Arnd Bergmann's avatar
      pinctrl: nomadik: hide nmk_gpio_get_mode when unused · caee57ec
      Arnd Bergmann authored
      nmk_gpio_get_mode is only used in one place, and that is conditionally
      compiled if DEBUG_FS is enabled. A recent cleanup has marked the
      definition 'static', which now leads to a warning:
      
      drivers/pinctrl/nomadik/pinctrl-nomadik.c:614:12: error: 'nmk_gpio_get_mode' defined but not used [-Werror=unused-function]
       static int nmk_gpio_get_mode(struct nmk_gpio_chip *nmk_chip, int offset)
                  ^~~~~~~~~~~~~~~~~
      
      Moving the function itself inside the #ifdef shuts it up again.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 5e81e0a0 ("pinctrl: nomadik: use BIT() with offsets consequently")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      caee57ec
  7. 28 Apr, 2016 2 commits
  8. 20 Apr, 2016 1 commit
  9. 01 Apr, 2016 1 commit
  10. 31 Mar, 2016 1 commit
  11. 05 Jan, 2016 1 commit
  12. 19 Nov, 2015 1 commit
    • Linus Walleij's avatar
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij authored
      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 <hskinnemoen@gmail.com>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Alek Du <alek.du@intel.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      58383c78
  13. 16 Oct, 2015 1 commit
  14. 16 Sep, 2015 1 commit
    • Thomas Gleixner's avatar
      genirq: Remove irq argument from irq flow handlers · bd0b9ac4
      Thomas Gleixner authored
      Most interrupt flow handlers do not use the irq argument. Those few
      which use it can retrieve the irq number from the irq descriptor.
      
      Remove the argument.
      
      Search and replace was done with coccinelle and some extra helper
      scripts around it. Thanks to Julia for her help!
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      bd0b9ac4
  15. 11 Aug, 2015 1 commit
  16. 27 Jul, 2015 2 commits
  17. 23 Jul, 2015 3 commits
  18. 17 Jul, 2015 1 commit
  19. 10 Jun, 2015 1 commit
  20. 06 May, 2015 2 commits
  21. 20 Oct, 2014 3 commits
  22. 30 Sep, 2014 1 commit
  23. 29 Sep, 2014 3 commits
  24. 23 Sep, 2014 1 commit
  25. 04 Sep, 2014 1 commit
  26. 11 Jul, 2014 2 commits
    • Linus Walleij's avatar
      pinctrl: nomadik: move all Nomadik drivers to subdir · 3a198059
      Linus Walleij authored
      We have a bunch of Nomadik family pin control drivers, so let's
      move them into their own subdirectory.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3a198059
    • Fan Wu's avatar
      pinctrl: avoid duplicated calling enable_pinmux_setting for a pin · 2243a87d
      Fan Wu authored
      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 = <GPIO48 AF6>;
        }
      
      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: default avatarFan Wu <fwu@marvell.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      Acked-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Acked-by: default avatarMaxime Coquelin <maxime.coquelin@st.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2243a87d
  27. 14 Apr, 2014 1 commit
  28. 26 Mar, 2014 1 commit
  29. 25 Mar, 2014 2 commits