1. 26 3月, 2018 1 次提交
  2. 03 1月, 2018 2 次提交
  3. 28 12月, 2017 1 次提交
  4. 20 12月, 2017 1 次提交
  5. 21 9月, 2017 1 次提交
  6. 29 5月, 2017 1 次提交
  7. 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
  8. 26 1月, 2017 1 次提交
  9. 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
  10. 03 1月, 2017 2 次提交
  11. 30 12月, 2016 1 次提交
  12. 17 11月, 2016 1 次提交
  13. 12 11月, 2016 2 次提交
  14. 05 11月, 2016 2 次提交
  15. 28 10月, 2016 2 次提交
  16. 22 6月, 2016 1 次提交
  17. 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
  18. 12 3月, 2016 1 次提交
  19. 17 11月, 2015 1 次提交
  20. 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
  21. 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
  22. 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
  23. 18 7月, 2015 2 次提交
  24. 16 7月, 2015 1 次提交
  25. 10 6月, 2015 1 次提交
  26. 06 5月, 2015 1 次提交
  27. 27 3月, 2015 1 次提交
  28. 20 10月, 2014 1 次提交
  29. 05 9月, 2014 1 次提交
  30. 04 9月, 2014 1 次提交
  31. 29 8月, 2014 2 次提交
  32. 11 7月, 2014 2 次提交