1. 04 9月, 2014 1 次提交
  2. 29 8月, 2014 2 次提交
  3. 11 7月, 2014 3 次提交
    • R
      pinctrl: pinctrl-single.c: Cleaning up wrong format string usage · bf4cef6c
      Rickard Strandqvist 提交于
      %d in format string used, but the type is unsigned int
      
      This was found using a static code analysis program called cppcheck
      Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      bf4cef6c
    • R
      pinctrl: pinctrl-single.c: Cleaning up values that are never used · 849bfe06
      Rickard Strandqvist 提交于
      Remove variable that are never used
      
      This was found using a static code analysis program called cppcheck.
      Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      849bfe06
    • F
      pinctrl: avoid duplicated calling enable_pinmux_setting for a pin · 2243a87d
      Fan Wu 提交于
      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: NFan Wu <fwu@marvell.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NPatrice Chotard <patrice.chotard@st.com>
      Acked-by: NHeiko Stuebner <heiko@sntech.de>
      Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      2243a87d
  4. 23 4月, 2014 1 次提交
    • T
      pinctrl: single: Clear pin interrupts enabled by bootloader · 58968625
      Tony Lindgren 提交于
      Since we set up device wake-up interrupts as pinctrl-single
      interrupts, we now must use the standard request_irq and
      related functions to manage them.
      
      If the pin interrupts are enabled for some pins at boot,
      the wake-up events can show up as constantly pending
      at least on omaps and will hang the system unless the related
      device driver clears the event at the device.
      
      To fix this, let's clear the interrupt flags during init,
      and print out a warning so the board maintainers can update
      their drivers to do proper request_irq for the driver specific
      wake-up events.
      
      Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      58968625
  5. 10 2月, 2014 1 次提交
    • C
      pinctrl: single: add low power mode support · 4bd75477
      Chao Xie 提交于
      For some silicons, the pin configuration register can control
      the output of the pin when the pad including the pin enter
      low power mode.
      For example, the pin can be "Drive 1", "Drive 0", "Float" when
      the pad including the pin enter low power mode.
      It is very useful when you want to control the power leakeage
      when the SOC enter low power mode, and can save more power for
      the low power mode.
      Signed-off-by: NChao Xie <chao.xie@marvell.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      4bd75477
  6. 15 1月, 2014 2 次提交
  7. 15 11月, 2013 1 次提交
  8. 19 10月, 2013 1 次提交
    • T
      pinctrl: single: Fix build when not built on ARM · 1b9c0fb3
      Tony Lindgren 提交于
      Looks like we need a little bit of arch specific handling
      with the generic IRQ. Fix the issue with an ifdef the
      same way as other drivers do.
      
      ARM needs things set to IRQF_VALID, which also then sets
      noprobe. Others seem to use just irq_set_noprobe().
      
      Otherwise we can get:
      
      drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
      drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of function 'set_irq_flags' [-Werror=implicit-function-declaration]
      drivers/pinctrl/pinctrl-single.c:1750:21: error: 'IRQF_VALID' undeclared (first use in this function)
      drivers/pinctrl/pinctrl-single.c:1750:34: error: 'IRQF_PROBE' undeclared (first use in this function)
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1b9c0fb3
  9. 11 10月, 2013 2 次提交
    • T
      pinctrl: single: Add support for auxdata · dc7743aa
      Tony Lindgren 提交于
      For omaps, we still have dependencies to the legacy code
      for handling the PRM (Power Reset Management) interrupts,
      and also for reconfiguring the io wake-up chain after
      changes.
      
      Let's pass the PRM interrupt and the rearm functions via
      auxdata. Then when at some point we have a proper PRM
      driver, we can get the interrupt via device tree and
      set up the rearm function as exported function in the
      PRM driver.
      
      By using auxdata we can remove a dependency to the
      wake-up events for converting omap3 to be device
      tree only.
      
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Prakash Manjunathappa <prakash.pm@ti.com>
      Cc: Roger Quadros <rogerq@ti.com>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dc7743aa
    • T
      pinctrl: single: Add support for wake-up interrupts · 3e6cee17
      Tony Lindgren 提交于
      The pin control registers can have interrupts for example
      for device wake-up. These interrupts can be treated as a
      chained interrupt controller as suggested earlier by
      Linus Walleij <linus.walleij@linaro.org>.
      
      This patch adds support for interrupts in a way that
      should be pretty generic, and works for the omaps that
      support wake-up interrupts. On omaps, there's an
      interrupt enable and interrupt status bit for each pin.
      The two pinctrl domains on omaps share a single interrupt
      from the PRM chained interrupt handler. Support for
      other similar hardware should be easy to add.
      
      Note that this patch does not attempt to handle the
      wake-up interrupts automatically unlike the earlier
      patches. This patch allows the device drivers to do
      a request_irq() on the wake-up pins as needed. I'll
      try to do also a separate generic patch for handling
      the wake-up events automatically.
      
      Also note that as this patch makes the pinctrl-single
      an irq controller, the current bindings need some
      extra trickery to use interrupts from two different
      interrupt controllers for the same driver. So it
      might be worth waiting a little on the patches
      enabling the wake-up interrupts from drivers as there
      should be a generic way to handle it coming. And also
      there's been discussion of interrupts-extended binding
      for using interrupts from multiple interrupt controllers.
      
      In any case, this patch should be ready to go allowing
      handling the wake-up interrupts in a generic way, or
      separately from the device drivers.
      
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Prakash Manjunathappa <prakash.pm@ti.com>
      Cc: Roger Quadros <rogerq@ti.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Benoît Cousson <bcousson@baylibre.com>
      Cc: devicetree@vger.kernel.org
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      3e6cee17
  10. 10 10月, 2013 1 次提交
  11. 28 8月, 2013 1 次提交
  12. 23 7月, 2013 1 次提交
  13. 18 6月, 2013 1 次提交
  14. 16 6月, 2013 2 次提交
  15. 14 5月, 2013 1 次提交
  16. 14 3月, 2013 1 次提交
  17. 07 3月, 2013 5 次提交
  18. 22 1月, 2013 1 次提交
    • H
      Revert "pinctrl: single: support gpio request and free" · 8b77b376
      Haojian Zhuang 提交于
      This reverts commit 2e8b2eab.
      
      Conflicts:
      	drivers/pinctrl/pinctrl-single.c
      
      ERROR: "__aeabi_uldivmod" [drivers/pinctrl/pinctrl-single.ko]
      undefined!]
      
      On Fri, Jan 11, 2013 at 4:00 PM, Russell King wrote:
      
      > The above error happens in builds including pinctrl-single - the
      > reason
      > is this, where resource_size_t may be 64-bit.
      >
      >                 gpio->range.pin_base = (r.start - pcs->res->start) /
      >                 mux_bytes;
      >                 gpio->range.npins = (r.end - r.start) / mux_bytes + 1;
      
      The reason of not fixing this issue and reverting the patch instead is
      this patch can't handle another case. It's not easy to handle multiple
      gpios sharing one pin register. So this gpio range feature will be
      implemented by other patches.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      8b77b376
  19. 04 1月, 2013 1 次提交
    • G
      Drivers: pinctrl: remove __dev* attributes. · 150632b0
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Barry Song <baohua.song@csr.com>
      Cc: Viresh Kumar <viresh.linux@gmail.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      150632b0
  20. 29 11月, 2012 3 次提交
  21. 23 11月, 2012 1 次提交
  22. 21 11月, 2012 1 次提交
  23. 15 11月, 2012 1 次提交
  24. 28 9月, 2012 1 次提交
  25. 13 9月, 2012 1 次提交
  26. 10 9月, 2012 1 次提交
  27. 15 7月, 2012 1 次提交