1. 21 9月, 2017 1 次提交
  2. 29 5月, 2017 1 次提交
  3. 07 4月, 2017 1 次提交
    • T
      pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable() · 61187142
      Tony Lindgren 提交于
      Recent pinctrl changes to allow dynamic allocation of pins exposed one
      more issue with the pinctrl pins claimed early by the controller itself.
      This caused a regression for IMX6 pinctrl hogs.
      
      Before enabling the pin controller driver we need to wait until it has
      been properly initialized, then claim the hogs, and only then enable it.
      
      To fix the regression, split the code into pinctrl_claim_hogs() and
      pinctrl_enable(). And then let's require that pinctrl_enable() is always
      called by the pin controller driver when ready after calling
      pinctrl_register_and_init().
      
      Depends-on: 950b0d91 ("pinctrl: core: Fix regression caused by delayed
      work for hogs")
      Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
      Fixes: e566fc11 ("pinctrl: imx: use generic pinctrl helpers for
      managing groups")
      Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Mika Penttilä <mika.penttila@nextfour.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Nishanth Menon <nm@ti.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Stefan Agner <stefan@agner.ch>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: NGary Bisson <gary.bisson@boundarydevices.com>
      Tested-by: NFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      61187142
  4. 26 1月, 2017 1 次提交
  5. 13 1月, 2017 1 次提交
    • T
      pinctrl: core: Fix regression caused by delayed work for hogs · 950b0d91
      Tony Lindgren 提交于
      Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
      regression at least with sh-pfc that is also a GPIO controller as
      noted by Geert Uytterhoeven <geert@linux-m68k.org>.
      
      As the original pinctrl_register() has issues calling pin controller
      driver functions early before the controller has finished registering,
      we can't just revert commit df61b366af26. That would break the drivers
      using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
      
      So let's fix the issue with the following steps as a single patch:
      
      1. Revert the late_init parts of commit df61b366af26.
      
         The late_init clearly won't work and we have to just give up
         on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
         GENERIC_PINMUX_FUNCTIONS.
      
      2. Split pinctrl_register() into two parts
      
         By splitting pinctrl_register() into pinctrl_init_controller()
         and pinctrl_create_and_start() we have better control over when
         it's safe to call pinctrl_create().
      
      3. Introduce a new pinctrl_register_and_init() function
      
         As suggested by Linus Walleij <linus.walleij@linaro.org>, we
         can just introduce a new function for the controllers that need
         pinctrl_create() called later.
      
      4. Convert the four known problem cases to use new function
      
         Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
         to use the new function to fix the issues. The rest of the drivers
         can be converted later. Let's also update Documentation/pinctrl.txt
         accordingly because of the known issues with pinctrl_register().
      
      Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Gary Bisson <gary.bisson@boundarydevices.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      950b0d91
  6. 03 1月, 2017 2 次提交
  7. 30 12月, 2016 1 次提交
  8. 17 11月, 2016 1 次提交
  9. 12 11月, 2016 2 次提交
  10. 05 11月, 2016 2 次提交
  11. 28 10月, 2016 2 次提交
  12. 22 6月, 2016 1 次提交
  13. 15 4月, 2016 1 次提交
    • K
      pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs · 56b367c0
      Keerthy 提交于
      pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
      ranging from 1 to MAX. This leads to a corner case where we try to request
      the pin number = MAX and fails.
      
      bit_pos value is being calculted using ffs. pin_num_from_lsb uses
      bit_pos value. pins array is populated with:
      
      pin + pin_num_from_lsb.
      
      The above is 1 more than usual bit indices as bit_pos uses ffs to compute
      first set bit. Hence the last of the pins array is populated with the MAX
      value and not MAX - 1 which causes error when we call pin_request.
      
      mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
      Consequently val_pos and submask are correct.
      
      Hence use __ffs which gives (ffs(x) - 1) as the first bit set.
      
      fixes: 4e7e8017 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
      Signed-off-by: NKeerthy <j-keerthy@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      56b367c0
  14. 12 3月, 2016 1 次提交
  15. 17 11月, 2015 1 次提交
  16. 16 9月, 2015 1 次提交
    • T
      genirq: Remove irq argument from irq flow handlers · bd0b9ac4
      Thomas Gleixner 提交于
      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: NThomas Gleixner <tglx@linutronix.de>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      bd0b9ac4
  17. 28 7月, 2015 1 次提交
    • R
      pinctrl: kill off set_irq_flags usage · 9458120e
      Rob Herring 提交于
      set_irq_flags is ARM specific with custom flags which have genirq
      equivalents. Convert drivers to use the genirq interfaces directly, so we
      can kill off set_irq_flags. The translation of flags is as follows:
      
      IRQF_VALID -> !IRQ_NOREQUEST
      IRQF_PROBE -> !IRQ_NOPROBE
      IRQF_NOAUTOEN -> IRQ_NOAUTOEN
      
      For IRQs managed by an irqdomain, the irqdomain core code handles clearing
      and setting IRQ_NOREQUEST already, so there is no need to do this in
      .map() functions and we can simply remove the set_irq_flags calls. Some
      users also modify IRQ_NOPROBE and this has been maintained although it
      is not clear that is really needed. There appears to be a great deal of
      blind copy and paste of this code.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Lee Jones <lee@kernel.org>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Tomasz Figa <tomasz.figa@gmail.com>
      Cc: Thomas Abraham <thomas.abraham@linaro.org>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-rpi-kernel@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-mediatek@lists.infradead.org
      Cc: linux-samsung-soc@vger.kernel.org
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9458120e
  18. 20 7月, 2015 1 次提交
    • G
      pinctrl: single: ensure pcs irq will not be forced threaded · c10372e6
      Grygorii Strashko 提交于
      The PSC IRQ is requested using request_irq() API and as result it can
      be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ
      is enabled for pinctrl domain.
      
      As result, following 'possible irq lock inversion dependency' report
      can be seen:
      =========================================================
      [ INFO: possible irq lock inversion dependency detected ]
      3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted
      ---------------------------------------------------------
      irq/369-pinctrl/927 just changed the state of lock:
       (&pcs->lock){+.....}, at: [<c0375b54>] pcs_irq_handle+0x48/0x9c
      but this lock was taken by another, HARDIRQ-safe lock in the past:
       (&irq_desc_lock_class){-.....}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&pcs->lock);
                                     local_irq_disable();
                                     lock(&irq_desc_lock_class);
                                     lock(&pcs->lock);
        <Interrupt>
          lock(&irq_desc_lock_class);
      
       *** DEADLOCK ***
      
      no locks held by irq/369-pinctrl/927.
      
      the shortest dependencies between 2nd lock and 1st lock:
        -> (&irq_desc_lock_class){-.....} ops: 58724 {
           IN-HARDIRQ-W at:
                             [<c0090040>] lock_acquire+0x9c/0x158
                             [<c07065c8>] _raw_spin_lock+0x48/0x58
                             [<c009edac>] handle_fasteoi_irq+0x24/0x15c
                             [<c009abb0>] generic_handle_irq+0x3c/0x4c
                             [<c000f83c>] handle_IRQ+0x50/0xa0
                             [<c0008674>] gic_handle_irq+0x3c/0x6c
                             [<c0707a04>] __irq_svc+0x44/0x8c
                             [<c000fc44>] arch_cpu_idle+0x40/0x4c
                             [<c009aadc>] cpu_startup_entry+0x270/0x2e0
                             [<c06fcbf8>] rest_init+0xd4/0xe4
                             [<c0a44bfc>] start_kernel+0x3d0/0x3dc
                             [<80008084>] 0x80008084
           INITIAL USE at:
                            [<c0090040>] lock_acquire+0x9c/0x158
                            [<c070674c>] _raw_spin_lock_irqsave+0x54/0x68
                            [<c009aff8>] __irq_get_desc_lock+0x64/0xa4
                            [<c009e38c>] irq_set_chip+0x30/0x78
                            [<c009ec30>] irq_set_chip_and_handler_name+0x24/0x3c
                            [<c036ca10>] gic_irq_domain_map+0x48/0xb4
                            [<c00a0a80>] irq_domain_associate+0x84/0x1d4
                            [<c00a1154>] irq_create_mapping+0x80/0x11c
                            [<c00a1270>] irq_create_of_mapping+0x80/0x120
                            [<c05cdaa8>] irq_of_parse_and_map+0x34/0x3c
                            [<c0a4ea24>] omap_dm_timer_init_one+0x90/0x30c
                            [<c0a4eef0>] omap5_realtime_timer_init+0x8c/0x48c
                            [<c0a486b0>] time_init+0x28/0x38
                            [<c0a44a6c>] start_kernel+0x240/0x3dc
                            [<80008084>] 0x80008084
         }
         ... key      at: [<c1049ce0>] irq_desc_lock_class+0x0/0x8
         ... acquired at:
         [<c07065c8>] _raw_spin_lock+0x48/0x58
         [<c0375a90>] pcs_irq_unmask+0x58/0xa0
         [<c009ea48>] irq_enable+0x38/0x48
         [<c009ead0>] irq_startup+0x78/0x7c
         [<c009d440>] __setup_irq+0x4a8/0x4f4
         [<c009d5dc>] request_threaded_irq+0xb8/0x138
         [<c0415a5c>] omap_8250_startup+0x4c/0x148
         [<c041276c>] serial8250_startup+0x24/0x30
         [<c040d0ec>] uart_startup.part.9+0x5c/0x1b4
         [<c040dbcc>] uart_open+0xf4/0x16c
         [<c03f0540>] tty_open+0x170/0x61c
         [<c0157028>] chrdev_open+0xbc/0x1b4
         [<c0150494>] do_dentry_open+0x1e8/0x2bc
         [<c0150a84>] finish_open+0x44/0x5c
         [<c0160d50>] do_last.isra.47+0x710/0xca0
         [<c01613a4>] path_openat+0xc4/0x640
         [<c0162904>] do_filp_open+0x3c/0x98
         [<c0151bdc>] do_sys_open+0x114/0x1d8
         [<c0151cc8>] SyS_open+0x28/0x2c
         [<c0a44d70>] kernel_init_freeable+0x168/0x1e4
         [<c06fcc24>] kernel_init+0x1c/0xf8
         [<c000eee8>] ret_from_fork+0x14/0x20
      
      -> (&pcs->lock){+.....} ops: 65 {
         HARDIRQ-ON-W at:
                          [<c0090040>] lock_acquire+0x9c/0x158
                          [<c07065c8>] _raw_spin_lock+0x48/0x58
                          [<c0375b54>] pcs_irq_handle+0x48/0x9c
                          [<c0375c5c>] pcs_irq_handler+0x1c/0x28
                          [<c009c458>] irq_forced_thread_fn+0x30/0x74
                          [<c009c784>] irq_thread+0x158/0x1c4
                          [<c0063fc4>] kthread+0xd4/0xe8
                          [<c000eee8>] ret_from_fork+0x14/0x20
         INITIAL USE at:
                         [<c0090040>] lock_acquire+0x9c/0x158
                         [<c070674c>] _raw_spin_lock_irqsave+0x54/0x68
                         [<c0375344>] pcs_enable+0x7c/0xe8
                         [<c0372a44>] pinmux_enable_setting+0x178/0x220
                         [<c036fecc>] pinctrl_select_state+0x110/0x194
                         [<c04732dc>] pinctrl_bind_pins+0x7c/0x108
                         [<c045853c>] driver_probe_device+0x70/0x254
                         [<c0458810>] __driver_attach+0x9c/0xa0
                         [<c045674c>] bus_for_each_dev+0x78/0xac
                         [<c0458030>] driver_attach+0x2c/0x30
                         [<c0457c78>] bus_add_driver+0x15c/0x204
                         [<c0458ee0>] driver_register+0x88/0x108
                         [<c045a168>] __platform_driver_register+0x64/0x6c
                         [<c0a8170c>] omap_hsmmc_driver_init+0x1c/0x20
                         [<c0008a94>] do_one_initcall+0x110/0x170
                         [<c0a44d48>] kernel_init_freeable+0x140/0x1e4
                         [<c06fcc24>] kernel_init+0x1c/0xf8
                         [<c000eee8>] ret_from_fork+0x14/0x20
       }
       ... key      at: [<c1088a8c>] __key.18572+0x0/0x8
       ... acquired at:
         [<c008cdd4>] mark_lock+0x388/0x76c
         [<c008df40>] __lock_acquire+0x6d0/0x1f98
         [<c0090040>] lock_acquire+0x9c/0x158
         [<c07065c8>] _raw_spin_lock+0x48/0x58
         [<c0375b54>] pcs_irq_handle+0x48/0x9c
         [<c0375c5c>] pcs_irq_handler+0x1c/0x28
         [<c009c458>] irq_forced_thread_fn+0x30/0x74
         [<c009c784>] irq_thread+0x158/0x1c4
         [<c0063fc4>] kthread+0xd4/0xe8
         [<c000eee8>] ret_from_fork+0x14/0x20
      
      stack backtrace:
      CPU: 1 PID: 927 Comm: irq/369-pinctrl Not tainted 3.14.43-rt42-00360-g96ff499-dirty #24
      [<c00177e0>] (unwind_backtrace) from [<c00130b0>] (show_stack+0x20/0x24)
      [<c00130b0>] (show_stack) from [<c0702958>] (dump_stack+0x84/0xd0)
      [<c0702958>] (dump_stack) from [<c008bcfc>] (print_irq_inversion_bug+0x1d0/0x21c)
      [<c008bcfc>] (print_irq_inversion_bug) from [<c008bf18>] (check_usage_backwards+0xb4/0x11c)
      [<c008bf18>] (check_usage_backwards) from [<c008cdd4>] (mark_lock+0x388/0x76c)
      [<c008cdd4>] (mark_lock) from [<c008df40>] (__lock_acquire+0x6d0/0x1f98)
      [<c008df40>] (__lock_acquire) from [<c0090040>] (lock_acquire+0x9c/0x158)
      [<c0090040>] (lock_acquire) from [<c07065c8>] (_raw_spin_lock+0x48/0x58)
      [<c07065c8>] (_raw_spin_lock) from [<c0375b54>] (pcs_irq_handle+0x48/0x9c)
      [<c0375b54>] (pcs_irq_handle) from [<c0375c5c>] (pcs_irq_handler+0x1c/0x28)
      [<c0375c5c>] (pcs_irq_handler) from [<c009c458>] (irq_forced_thread_fn+0x30/0x74)
      [<c009c458>] (irq_forced_thread_fn) from [<c009c784>] (irq_thread+0x158/0x1c4)
      [<c009c784>] (irq_thread) from [<c0063fc4>] (kthread+0xd4/0xe8)
      [<c0063fc4>] (kthread) from [<c000eee8>] (ret_from_fork+0x14/0x20)
      
      To fix it use IRQF_NO_THREAD to ensure that pcs irq will not be forced threaded.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c10372e6
  19. 18 7月, 2015 2 次提交
  20. 16 7月, 2015 1 次提交
  21. 10 6月, 2015 1 次提交
  22. 06 5月, 2015 1 次提交
  23. 27 3月, 2015 1 次提交
  24. 20 10月, 2014 1 次提交
  25. 05 9月, 2014 1 次提交
  26. 04 9月, 2014 1 次提交
  27. 29 8月, 2014 2 次提交
  28. 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
  29. 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
  30. 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
  31. 15 1月, 2014 2 次提交